🚀СAP теорема

#distsys

Суть CAP - теореми полягає в тому, що в розподілених системах неможливо ОДНОЧАСНО забезпечити узгодженість (consistency), доступність (availability) та стійкість до розділення (partition tolerance)

Це означає, що під час розділенням мережі треба жертвувати однією з властивостей (тимчасово). Часто також використовують eventual consistency - тобто дані синхронізуються з часом.

Що ж робити при розділенні?

Ризик розділенням мережі завжди високий, тому інженерам треба обирати:

👉 CA (узгодженість та доступність) - рідко буває в реальних умовах. Як приклад - база даних на одному сервері, без кластеризації.

👉 CP (узгодженість та стійкість) - система відмовляє у відповідях поки дані не синхронізовані. Наприклад MongoDB, Redis, HBase

👉 AP (доступність та стійкість) - дані тимчасово відрізняються на різних вузлах, але система доступна. Наприклад Cassandra, DynamoDB, CouchDB

Ну то й що?

Знаючи теорему, можна розуміти, з яким типом системи ми працюємо та як це впливає на тестування.

⚡️ Епізод 54: Про дослідницьке тестування

Що таке дослідницьке тестування? Чи це просто випадкове клацання без цілі в надії знайти ті чи інші баги? Чим дослідницьке тестування відрізняється від звичного тестування за тест кейсами? Як визначають дослідницьке тестування різні спеціалісти? На всі ці питання будуть шукати відповідь ведучі подкасту - Артем та Олександр

Дивитись та слухати:
🔸 Youtube
🔹 Spotify
🔸 Apple

Ваша підтримка важлива!
Ми постійно розвиваємося і рухаємося вперед, але це неможливо без вашої підтримки. Тому будемо вдячні за лайки, коментарі та будь-яку іншу форму підтримки. Це допоможе нам просувати наші подкасти в рекомендаціях.

Дякуємо вам!

Також ви можете стати спонсором нашого подкасту на YouTube, це допоможе нам покращувати якість нашого контенту!

#testingminutes | @a_grygorenko | Test Engineering Notes

Три кроки для боротьби з рутиною в тестуванні, які допомогли мені

#testing #career

- "Нічого нового в тестуванні"
- "Все вже й так зрозуміло"
- "Таски всі однакові, доповіді всі однакові"
- "Тестування та АйТі перестало бути цікавим"
- "Booooring!"

Саме такі питання виникають в мене час від часу.

Що допомагає мені в такому випадку?

1️⃣ Розширьте коло інтересів: розробка, менеджмент (в тому числі й продуктовий), девопс, безпека, перфоманс, ШІ й інші технології. Знайдіть те, що зможе дати той самий "вогник цікавості" знову
2️⃣ Займіться хоббі (бажано не звʼязаному з АйТі). Погрузіться в нього з головою.
3️⃣ Візміть відпустку. Читайте й дивіться тільки контент не звʼязаний з роботою.

Я застосував усі три способи. То ж зараз маю трохи інший погляд на те, що мені цікаво в тестуванні. А також декілька інших інженерних (й не тільки) тем та хоббі.

А що допомагає Вам?

Тестування безпеки LLM систем

#ai #llm #security #testing

Багато хто користується LLM системами, такими як ChatGPT, Claude, Gemini та інші. Дехто - тестує інтеграцію таких систем з власними продуктами. А хтось навіть розробляє свої власні LLM системи для внутрішнього користування.

Але що там з безпекою LLM-ок? Виявляється, prompt injection атаки то не вигадка, а реальна загроза. Бо ШІ може погано розрізняти системні запити та користувацькі запити. В такому випадку зловмисник може відносно легко обійти авторизацію, закинути SQL інʼєкцію чи навіть виконати команди віддалено.

Деякі корисні ресурси з теми:
- Гайд по вразливостям від OWASP
- Обмеження в тестуванні LLM систем
- Як саме виконувати prompt injection

Тренуватись можна тут: Portswigger Web LLM attacks

⚡️ Епізод 55: Про паттерни в автоматизації (й не тільки)

Перший автотест вже написаний та успішно запускається на CI. Але як писати код так, щоб він був зрозумілий, швидкий та розширюваний? Як для цього використовуються паттерни та інші абревіатури як DRY, SOLID та KISS? Допомагати розібратись в цьому ведучим подкасту, Артему та Олександру, буде гість - Костянтин Телтов.

Дивитись та слухати на Youtube ---> ТУТ

Ваша підтримка важлива!

Ми постійно розвиваємося і рухаємося вперед, але це неможливо без вашої підтримки. Тому будемо вдячні за лайки, коментарі та будь-яку іншу форму підтримки. Це допоможе нам просувати наші подкасти в рекомендаціях. Також ви можете стати спонсором нашого подкасту, це допоможе нам покращувати якість нашого контенту!

Дякуємо вам!

#testingminutes | @a_grygorenko | Test Engineering Notes

🥳 З Днем Тестувальника!

#testing

Сьогодні 9 вересня - то ж вітаю усіх тест інженерів із професійним святом. 

Хочеться побажати бути інженерами, а не просто тестерами. 

Тестер просто перевіряє софт по тест кейсам та репортить результат. "Немає білду - сидимо тихо."

Тест-інженер аналізує ризики, розуміє бізнес домен та проблеми. Інженер знає багато технік й інструментів й може їх застосовувати ефективно. Інженер може й хоче автоматизувати свою роботу. Інженер знає, що інформацію про якість треба доносити по-різному в залежності від співрозмовника.

Тестери (як і кодери) можуть бути легко замінені ШІ. Інженери ще мають час. А там - подивимось.

⚡️ Епізод 56: Про метрики в тестуванні

В одному з попередніх епізодів ми розбирались із шкідливими метриками. Але які метрики є корисними? Що треба трекати на проєкті? Як обрати найкращу метрику? В цьому епізоді подкасту, Артем та Олександр поринають у чарівний світ метрик в тестуванні.

Дивитись та слухати:
🔸 Youtube

Ваша підтримка важлива!

Ми постійно розвиваємося і рухаємося вперед, але це неможливо без вашої підтримки. Тому будемо вдячні за лайки, коментарі та будь-яку іншу форму підтримки. Це допоможе нам просувати наші подкасти в рекомендаціях. Також ви можете стати спонсором нашого подкасту на YouTube, це допоможе нам покращувати якість нашого контенту!

Дякуємо вам!

#testingminutes | @a_grygorenko | Test Engineering Notes

Programming Deflation

#engineering

Свіжа стаття від Кента Бека про те, як змінюється розробка в сучасному світі ШІ.

Багато цікавих питань:
- В епоху тотального ШІ нам потрібно буде менше чи більше розробників?
- Якщо написання програм стає все більш дешевим - чи не краще почекати ще пару років, коли написання програм буде зовсім безкоштовним?
- Як змінюється якість коду коли більшість його генерується ШІ?
- Чому дешевший код призводить до пришвидшення інновацій?

Головна думка:

В світі надзвичайно дешевого коду найбільш дефіцитним стає .. РОЗУМІННЯ, СУДЖЕННЯ. Здатність бачити як частини поєднуються разом. Знання, коли та що НЕ ТРЕБА створювати.

Ці навички можуть мати зрілі та досвідчені фахівці. А ось як здобути ці навички, коли ти джуніор та весь код за тебе пише ШІ - оце інше велике питання.

⚡️ Епізод 57: Роздуми про роботу в офісі або на ремоуті

Спочатку ми працювали в офісах. Потім прийшов ковід та віддалена робота. Тепер багато компаній повертає людей в офіси (чи хоча б на гібридний формат). Але в чому причина повернення? Що краще - працювати віддалено чи в офісі? В цьому будуть розбиратися ведучі подкасту - Артем та Олександр.

Дивитись та слухати:
🔸 Youtube

Ваша підтримка важлива!

Ми постійно розвиваємося і рухаємося вперед, але це неможливо без вашої підтримки. Тому будемо вдячні за лайки, коментарі та будь-яку іншу форму підтримки. Це допоможе нам просувати наші подкасти в рекомендаціях. Також ви можете стати спонсором нашого подкасту на YouTube, це допоможе нам покращувати якість нашого контенту!

Дякуємо вам!

#testingminutes | @a_grygorenko | Test Engineering Notes

Головна подія української QA-спільноти — конференція тестувальників «Бетельгейзе» очікує на тебе вже 18-19 жовтня (онлайн)!

Це 2️⃣ дні, що насичені найцікавішими подіями — від доповідей до дискусій.

➡️ 1 день: доповіді
🟢2 потоки, в кожному з яких 6-7 доповідей
🟢Спікери з різних галузей для обміну досвідом: від Middle QA до керівників відділів та засновників.

➡️ 2 день: дискусії
🟢1 потік, 6 дискусій на найактуальніші теми, серед яких окрема увага до ШІ.

Відвідувачам будуть доступні записи всіх подій.

🔈 Увага! Підвищення ціни з 6 жовтня!

Дивись програму та деталі доповідей на сайті конференції 👈

⚖️ Про результативність та ефективність

#engineering

В інженерії можна зустріти два терміни, які повʼязані між собою, але мають різне значення.

Результативність (effectiveness) - відповідає на питання чи досягли ми поставленої цілі, чи отримали очікуваний результат. Коротко - "робити ПРАВИЛЬНІ речі".

Ефективність (efficiency) - означає чи використали ми наявні ресурси оптимально. Коротко - "робити речі ПРАВИЛЬНО". В ідеалі використати якнайменше часу, зусиль, коштів для досягнення результату.

Щоб підвищити продуктивність команди чи процесу, треба покращувати результативність ТА ефективність.

Як ШІ замінить менеджерів

#python #ai

import time
import random

def random_status_prompt():
    prompts = [
        "What is your current status?",
        "Any blockers?",
        "Update your JIRA, please."
    ]

    # Sleep for a random number of minutes (converted to seconds)
    sleep_minutes = random.randint(1, 10)
    print(f"Sleeping for {sleep_minutes} minute(s)...")
    time.sleep(sleep_minutes * 60)

    # Pick a random prompt and display it
    message = random.choice(prompts)
    print(message)

if __name__ == "__main__":
    random_status_prompt()

🚀 Про інтуїцію в тестуванні

#testing #learning

Під час однієї з дискусій на конференції Бетельгейзе ми говорили про те, які задачі тестувальника ми (поки що) не можемо передати в руки алгоритмам штучного інтелекту.

Основна думка була в тому, що ШІ не має тієї інтуїції та того контексту, який має тест інженер, залучений у проєкт. Але що таке інтуїція?

Інтуїція в тестуванні

Серед технік тест дизайну є одна, що називається error guessing, себто вгадування помилок. Вона базується на здатності тестувальника знаходити та передбачувати появлення дефектів на основі досвіду минулих, схожих, помилок в подібних компонентах. Тобто ця техніка передбачає наявність в тестувальника ... інтуїції.

Інтуїція в навичках

Якщо дивитися на модель Дрейфуса, то існує пʼять рівнів володіння навичками: новачок, просунутий новачок, компетентний, вправний та експерт.

👉 Новачкам потрібні чіткі інструкції (можна назвати їх промптами)
👉 Просунутим новачкам теж потрібні інструкції, але вони вже можуть пробувати виконувати щось по-своєму.
👉 Компетентні люди вже можуть досліджувати проблеми та виправляти їх самостійно.
👉 Просунуті - можуть аналізувати роботу інших та виправляти самих себе. Саме тут найбільше застосовуються ті самі фундаментальні знання.
👉 Експерти - працюють на основі інтуїції. А інтуїція будується на досвіді та практиці. Експерти знають різницю між важливими та нерелевантними деталями. Експерт знає на яких з них дійсно треба фокусуватись - бо має розвинуту здатність до pattern matching (співставляння зі зразками)

Тож новачкам (та ШІ) треба давати чіткі вказівки. Вчіться робити ці інструкції точно та зрозуміло. Зважайте на контекст!
А от експерти від таких чітких правил стагнують та страждають.

Нажаль, в деяких організаціях інтуїції забороняють застосовувати бо вона не “повторювана” чи то не “наукова”. Якщо ви менеджер - дайте можливість експертам застосовувати інтуїцію.

Що ж нам з усим цим робити?

⚡️ Ставайте експертами в своєму продукті та тих навичках, якими володієте.
⚡️ Розвивайте здатність отримувати нові відкриття з багатьох джерел, співставляти факти, застосовувати свій досвід.
⚡️ Щоб мати можливість опиратися на цей досвід - треба вміти цей досвід помічати, записувати, оцінювати та рефлексувати. (Тут знову згадаю про важливість нотаток)

А ось не треба натякати українцям, що останній лимон захований десь на AWS S3 бакеті ...

Чи потрібно отримувати сертифікат ISTQB?

Я й сам не знаю 😀!

Але цієї суботи є можливість в цьому розібратись. А ще - побачити які взагалі є модні й молодіжні ISTQB сертифікації (включно з GenAI). Та ще й у форматі просмажки.

📅 Коли: 25 жовтня
💻Де: онлайн
💡Скільки коштує: безкоштовно

Не забудьте зареєструватись 👉 https://certifiedunicorns.pro/hot-istqb-conference

Починаю читати свіжачок. Цікаво, що там діди (Michael Bolton & James Bach) написали.

P.S. Огляд та розбір буде згодом.

Taking Testing Seriously - Огляд (1)

#testing #books

На минулому тижні я прочитав нову книжку від Джеймса Баха та Майкла Болтона під назвою "Taking Testing Seriously".

В наступних постах я зроблю детальний огляд найбільш цікавих моментів з книги. А читати її чи не читати - ви вже вирішуйте самі.

🎓Про що ця книга?

Коротко - книга розповідає про методологію тестування, якої навчають автори книги. Методологія ця називається "Rapid Software Testing". Курси з неї Бах та Болтон ведуть вже більше двох десятків років - то ж щось в цьому мабуть є.

📖 Розділ 1 - Why Another Book About Testing?

У першому розділі автори розмірковують - нащо вони написали "ще одну" книжку з тестування.

Спочатку, автори знайомлять нас з різними школами тестування: factory, quality, agile, analytical, context-driven. (А ви чули про такі школи тестування? Якщо ні - можу більше про них розповісти)

💡Rapid Software Testing є методологією контекстно-орієнтованого тестування.

Далі, Джеймс та Майкл починають роздивлятись саме поняття тестування та його аналогії з реальним світом.

- Автори порівнюють тестування на проєкті із фарами автомобіля. Фари не сповільнюють рух авто, так само й тестування не сповільнює проєкти. Тестування, навпаки, дозволяє проєктам рухатися швидше.
- Щодо того, щоб запобігати багам, замість тестування - автори задають питання: а як ми зрозуміємо, що запобігли усім багам?
- Майкл та Джеймс також зазначають, що тестування - це пошук правди про продукт. Деякі люди не бажають знати правду - бо знання правди створює відповідальність. Тож деякі менеджери сподіваються, що тестери не знайдуть ніяких багів. Або ж звинувачують тестувальників в тому, що вони знайшли баги. Як результат - тестери починають репортити менше багів, щоб отримати менше звинувачень.

Також автори зазначають, що використання GenAI та підходів типу vibe coding додає ще більше роботи з тестування. Як розробникам, так і тестувальникам. (З цього приводу напишу окремий пост, бо якраз досліджую це питання).

На цьому перший розділ закінчений, побачимось в наступних.

📹 Як обрати собі школу тестування

#testing #video

🏫 Вчора, в огляді на книгу Баха й Болтона, я згадав такі штуки, як школи тестування.

То ж сьогодні хочу поділитись відео своєї доповіді з конференції QADay, де я розповідаю саме про цю тему.

❗️І так, ЦЕ НЕ ПРО КУРСИ 😀

📖 Taking Testing Seriously - Огляд 2

#testing #books

Попередні огляди: 1

Продовжуємо огляд книги Джеймса Баха та Майкла Болтона. Сьогодні я коротко розповім про вам про розділ 2 під назвою "Foundation"

💡Що таке тестування (згідно з авторами книги)?

Тестування - процес оцінки продукту шляхом вивчення його через досвід, дослідження та експериментування з ним.

Ключове тут саме "оцінка .. через вивчення". Тестувальник збирає докази під час тестування, фільтрує їх та конструює історію про те, що сталося та що це означає.

Тестування включає в себе багато процесів: моделювання, опитування, вивчення, вибірка, спостереження, розуміння та розповідь історій.

В методології "Rapid Software Testing" існує різниця між тестуванням (testing) та перевіркою (checking). Тестування може зробити тільки досвідчена людина. Перевірку - може зробити машина. Можна провести паралель із програмуванням та компілюванням. Програмують люди, а машина потім компілює код.

Доречі - не існує ручного чи автоматизованого програмування. Є програмування (із застосуванням інструментів). Як тільки інструмент працює достатньо надійно - це не називають програмуванням. Називають компіляцією, статичним аналізатором коду, тощо.

Так само є тестування із застосуванням інструментів. А є - автоматизовані перевірки. Автори розділяють тестування та перевірку тому, що не існує "автоматизованого тестування".

Чи значить що з ШІ програмісти стануть не потрібні? Відповідь - ні, бо ШІ не несе відповідальності за код, який згенерувало. Це задача програміста інтегрувати та перевірити код, що написаний машиною.

🎭 Різниця між тестуванням та виконанням тесту

Автори відмічають, що

тест - це зустріч із продуктом, що становить тільки один з епізодів тестування.

А також:

Тест - це наче сценарій пʼєси, що написав драматург. Тестування - це те, що роблять актори на сцені.

Виконати тест означає налаштувати систему, керувати нею, спостерігати та оцінювати продукт певним чином, в певний час. Тестування ж включає ще підготовку до тестів, комунікацію з людьми.

На цьому все. До зустрічі в наступному пості.

🧰Проблеми з ШІ інструментами з точки зору інженера - Частина 1

#testing #engineering #ai

ШІ повсюди. ШІ вже тут. Стережися ШІ!

Останній рік (чи може трохи більше) помічаю ажіотаж з використання ШІ.

⚡️ Лідери думок говорять на конференціях, що ШІ вже тут та забере наші робочі місця
⚡️ Менеджмент давить на лідів, щоб вони скоріш впроваджували ШІ де тільки можна
⚡️ Курси пропонують “чарівні” таблетки для тестувальників у вигляді підбірки промтів на всі випадки життя
⚡️ Деякі блогери пропагують вайб кодинг - як майбутнє програмування й тестування

❓Але постає питання - а чи дійсно ШІ є тією чарівною пігулкою, що зробить вашу роботи тестувальника чи автоматизатора набагато легше? Чи дійсно ШІ допоможе стати більш ефективним?

🎓Чому мені то цікаво?

Мої колеги та знайомі користуються ШІ кожного дня. Я сам користуюся ChatGPT, Claude, Perplexity, Gemini, Cursor. Пробував також Github Copilot.

Але я відношуся до цих інструментів з долею скептицизму. Бо будь-яка технічна магія, яку ми, як тест інженери, не розуміємо, може призвести до великих проблем в продукті.

До того ж - треба вміти користуватися тими інструментами ефективно.

💡 Що таке вайб кодинг?

Вайб кодинг — це дослідницький підхід до розробки програмного забезпечення, що орієнтований на підказки, де розробники швидко генерують підказки, отримують код та виконують ітерації.

Гарно вайб кодити - це як вміти правильно просити побажання у лепрекона, де як би точно ви не намагалися описати та виправити прохання, результат ніколи не буває зовсім правильним.

Але чим більше розробник вайбкодить - тим більше зростає ризик, що він не перевірить результать ШІ та й зафігачить купу “наче працюючого” коду в мастер гілку.

🕶Проблеми з вайб кодингом та сучасними ШІ (LLM-ками)

Але сила вайб кодингу приходить із відповідальність (а точніше із проблемами ШІ):

👉 Галюцинації. ШІ генерує купу коду, який гарно виглядає, але не факт, що правильно працює. ШІ доволі легко може згенерувати тести на неіснуючі ендпоінти. Або ж зробити ці тести “зеленими” просто прибравши assertʼи.

👉 Надмірна впевненість. Девелопер з часом сприймає будь-які результати ШІ як правильні. Цим грішать навіть досвідчені інженери.

👉 Цикли перефразування. Коли інженер модифікує промт для досягнення кращого результату від ШІ. А ШІ генерує одні й тіж шматки коду та рішення (можливо виражені іншим чином)

Крім того, коли ШІ генерує багато коду, а менш досвідчена людина додає цей код в проєкт - виростають ризики появи дублікатів, поганої інтеграції та абстракції без міри.

Але це ще не всі проблеми. Бо є парадокс когнітивного спрощення. Що це таке - вже в наступному пості.