⛓ Види залежностей в розподілених системах

#distributedsystems

👉 Процесна залежність. Якщо процес P виконує операцію А, а потім - B, то операція B процесно залежить від А.

👉 Залежність сесій. Сессія, то є послідовність операцій, які виконується по порядку. Залежність в контексті сесії означає, що операція В залежить від операції А - коли операція А виконується строго перед операцією В.

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

👉 Залежність читання - запис. Залежність такого роду виникає, коли операція А читає якусь версію v1 обʼєкту, а операція В записує наступну версію цього ж обʼєкта.

👉 Залежність запис - читання. Операція А записує версію обʼєкту, а операція В повинна успішно прочитати нову версію.

👉 Залежність запис-запис. Операція А записує свою версію обʼєкту, а операція В перезаписує обʼєкт.

🤷Чому це важливо? Знання залежностей допоможуть надалі розібратися із моделями узгодженості.

🤖20+ книг з автоматизації тестування 📖

#automation #books

Знайшов я тут декілька підбірок книжок з автоматизації тестування: один, два. Там є хороші книжки, є й не дуже. Деякі - вже застарілі або ж якісь невідомі.

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

🪄Що почитати з автоматизації тестування?

📚 Contract Testing in Action: With Pact, PactFlow, and GitHub Actions (2025)
📚 Software Testing with Generative AI (2024)
📚 Software Testing Strategies: A testing guide for the 2020s (2023)
📚 Automation Awesomeness: 260 actionable affirmations to improve your QA and automation testing skills (2023)
📚 Test Automation Engineering Handbook (2023)
📚 Effective Software Testing: A developer's guide (2022)
📚 Testing Web APIs (2022)
📚 Full Stack Testing: A Practical Guide for Delivering High Quality Software (2022)
📚 Test Automation Fundamentals (2022)
📚 Software Testing: A Craftsman’s Approach, Fifth Edition (2021)
📚 Team Guide to Software Testability (2021)
📚 Test Automation: A manager's guide (2021)
📚 Software Engineering at Google (2020)
📚 Complete Guide to Test Automation: Techniques, Practices, and Patterns for Building and Maintaining Effective Software Projects (2018)
📚 Testing Java Microservices: Using Arquillian, Hoverfly, AssertJ, JUnit, Selenium, and Mockito (2018)
📚 Developer Testing: Building Quality into Software (2016)
📚 The "A" Word. Under the Covers of Test Automation (2013)
📚 Experiences of Test Automation: Case Studies of Software Test Automation (2012)
📚 How Google Tests Software (2012)
📚 Implementing Automated Software Testing: How to Save Time and Lower Costs While Raising Quality (2009)
📚 xUnit Test Patterns: Refactoring Test Code (2007)
📚 Lessons Learned in Software Testing: A Context-Driven Approach (2001)

P.S. Чи цікаві вам будуть огляди на ці книжки? На які саме?
P.P.S. А які книжки з автоматизації тестування читали ви?

⚡️ Епізод 53: Куди можна рости в тестуванні?

Куди можна рости в тестуванні? Це питання задає собі як починаючий інженер, так і досвідчений спеціаліст. Чи всім треба йти в автоматизацію? Чи лідерство - то єдиний можливий варіант розвитку? Разом із ведучими подкасту, Артемом та Олександром, ми будемо розбиратися які варіанти карʼєрного розвитку існують.

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

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

Дякуємо вам!

Підтримати подкаст можна через: 🏦 База від Монобанку

#testingminutes | @a_grygorenko | Test Engineering Notes

⏰Доступність (в розподілених системах)

#distsys

Що таке доступність?

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

Види доступності

👉 Повна доступність: кожен справний вузол може виконувати будь-яку операцію. Операції виконуються навіть тоді, коли інші вузли або мережа між ними виходять з ладу

👉Системи з доступною більшістю: якщо більшість невідмовних вузлів можуть спілкуватися один з одним, ці вузли можуть виконувати операції. Більшість може бути як 50% + 1 або 2/3 + 1 вузли

👉 Фіксована (sticky) доступність: якщо клієнт виконує операцію зі станом бази даних, який відображає всі попередні транзакції клієнта, він зрештою отримує відповідь – навіть за наявності невизначеної кількості збоїв вузлів або мережі

❗️Важливо!

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

👌Узгодженість (в розподілених системах)

#distsys

❓Що таке узгодженість?

Узгодженість - це коли кожен клієнт отримує від системи одні й ті самі (найбільш актуальні) дані, незалежно від того, з яким вузлом взаємодіє.

Види узгодженості

👉 Сильна узгодженість. Кожне читання видає останню версію запису.

👉 Кінцева узгодженість. Читання може видати не останню версію даних, але згодом усі дані синхронізуються.

👉 Узгодженість читання-запису. Клієнт, що записує, може одразу считати записані дані.

👉 Причинно-наслідкова узгодженість. Дані, що залежать один від одного повинні бути прочитані по порядку.

👉 Монотонна узгодженість. Коли клієнт оновив дані, він не отримає минулу версію даних.

❗️Важливо!

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

✂️Толерантність до розділення (в розподілених системах)

#distsys

❓Що таке толерантність до розділення?

Розподілені системи складаються з вузлів, що комунікують через мережу. Але мережа - не завжди стабільна. Звʼязок між вузлами може обірватися. Тоді система розпадається на дві або більше групи вузлів.

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

Що робити, коли система розділена?

У випадку розділення, розподілена система має два варіанти:

👉Забезпечити доступність. Система відповідає без затримок, але дані можуть відрізнятись у кожній групі вузлів (тимчасово)

👉Забезпечити узгодженість. Система припиняє записи, поки всі вузли (або більшість) не матимуть однакових даних. Доступність буде обмежена в такому випадку.

❗️Тобто, у випадку розділення мережі вузлів система або повністю доступна або обмежено доступна (але гарантує коретність даних)

🚀С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 бакеті ...