"An engineer’s peaceful sleep: how we ensure quality to rest easy", Andrii Yurchenko

I’ll share my experience in writing automated tests that help avoid surprises in production and explain how we integrate them with the testing system. At the same time, we’ll discuss whether documentation is really necessary if the tests already “speak” for the system.

1. 10+ років комерційної розробки 4+ років у TENTENS Tech Не боюсь вриватись у legacy проєкти і робити їх Great Again Люблю яхтинг, лижі і картинг АНДРІЙ ЮРЧЕНКО Senior Backend Developer at TENTENS Tech

2. TENTENS Tech 40+ Деплоїв на день Ми займаємось розробкою платформ для комунікації користувачів 10 Команд розробки 15К RPS Пікове навантаження, яке продовжує зростати

3. ТЕХНОЛОГІЧНИЙ СТЕК PHP8.2+ / GoLang MySQL, Memcached, MongoDB Frameworks: Yii2, Symfony Комунікація: GRPC, JsonAPI, RabbitMQ, GraphQL Microservices, Clean Architecture, CQRS, DDD, Hexagonal Architecture

4. ЧИ ТРАПЛЯЛОСЬ З ВАМИ ? Вас будить дзвінок з роботи серед ночі

5. ЩО ЗАБИРАЄ СОН ІНЖЕНЕРА А чи працює це? НЕВИЗНАЧЕНІСТЬ НЕВПЕВНЕНІСТЬ Як це працює?

6. Середньостатистичний цикл у вакуумі ЖИТТЄВИЙ ЦИКЛ ФІЧІ Усі співпадіння вигадані 01 02

7. Отрима ли оформлену задачу Розібрались, що треба зробити Написали код і тести Пройшли код-ревью Протестували з тестувальником функціонал Доставили код в production Протестували з тестувальником функціонал на production PROFIT! ЖИТТЄВИЙ ЦИКЛ ФІЧІ

8. ПРОБЛЕМИ?

9. ТЕСТУВАЛЬНИКИ ВЕСЬ СПРИНТ

10. ТЕСТУВАЛЬНИКИ В ОСТАННІЙ ДЕНЬ СПРИНТА

11. КОШМАР РОЗРОБНИКА Ми не можемо завтра доставити задачу, бо не встигаємо її протестувати

12. Тестувальник стає вузьким місцем Кожній команді потрібен тестувальник, а може й декілька Розмита відповідальність за фічу Фрагментовані знання – кожен знає свою частину пазлу 01 02 03 04 ПРОБЛЕМИ

13. РІШЕННЯ GENERAL QUALITY ASSURANCE ENGINEER К оманда самостійно проводить тестування

14. Тестувальник стає вузьким місцем Кожній команді потрібен тестувальник, а то і декілька Розмита відповідальність за фічу Фрагментовані знання – кожен знає свою частину пазлу 01 02 03 04 ПРОБЛЕМИ

15. ЧИ ТРАПЛЯЛОСЬ З ВАМИ? Ви отримали задачу, але гадки не маєте, що, в біса, відбувається

16. Вимоги не зафіксовані Не має чіткого технічного рішення Потрібно внести зміни в існуючий функціонал, але він знаходиться в іншій зоні відповідальності Фрагментовані знання – кожен знає свою частину пазлу ПРОБЛЕМИ 01 02 03 04

17. НАШІ ПІДХОДИ BUSINESS REFINEMENT TECH REFINEMENT Зустріч, де ми обговорюємо вже описану бізнес-ініціативу Узгоджуємо вимоги і вирішуємо: чи можемо реалізувати Якщо задача виконується в декількох зонах – описуємо System-design Збираємо всі технічні деталі: як саме будемо реалізовувати фічу та які зміни в які саме зони будемо вносити

18. МИ ПИШЕМО КОД Перейдемо до тестування

19. ЯК МИ ТЕСТУЄМО Запуск статичних тестів (code style, deptrack) Unit + Integration Code review Ручне тестування на stage (postman, manual) Autotests Smoke – швидкі тести, які тестують критичні сценарії Regression – довгі UI-тести, які тестують систему з точки зору користувача

20. UNIT TEST Тест однієї функціональної одиниці Залежності ізольовані Фокус : доменні моделі, д оменні сервіси, мапери, валідатори запитів

21. AAA PATTERN Triple A pattern – це патерн для структурування тестів, щоб вони були простими і зрозумілими. * ARRANGE (Підготовка) П ідготовка вхідних даних та залежностей ACT (Дія) Виклик методу, який тестуємо (Перевірка) Перевіряємо чи збігається фактичний результат з очікуваним ASSERT

22. AAA PATTERN

23. INTEGRATION TEST Тестуємо use-caseʼи, інтеграції із зовнішніми системами (Mysql), або комплексну логіку. Залежності не ізольовані або ізольовані частково. Фокус: залежності збираються коректно, процес виконується очікувано, перевіряємо тільки те, що важливо. Потребують екосистеми для свого існування, відносно дорогі.

24. ТЕСТОВА ДОКУМЕНТАЦІЯ Розробники та QA- інженери описують сценарії тестування Єдина точка збереження знань дозволяє швидкий шерінг знань між розробниками Розуміння, що покрито автотестами, а що ні Система керування тестами: manual / autotest

25. СТРАТЕГІЯ ТЕСТУВАННЯ ЗАЛЕЖИТЬ ВІД: Стадії розвитку компанії Архітектури вашого застосунку Структури компанії Ресурсів компанії Задачі 01 02 03 04 05

26. ПОРІВНЯЛЬНА ТАБЛИЧКА Покриття Фокус Швидкість Стабільність Ціна Unit Функція, класс Логіка в ізоляції Ш видкі В исока $ Integration А даптер, use-case, endpoint Взаємодія та відповідність С ередня С ередня $$ E2E UI, endpoint Бізнес- сценарій П овільні Н изька $$$$

27. ЧИ ТРАПЛЯЛОСЬ З ВАМИ? Доставили задачу в production та поклали його

28. PRODUCTION ПІСЛЯ ДЕПЛОЮ В МАЙБУТНЬОМУ Код має вміти: як швидко потрапити в production, так і швидко його покинути Швидко зрозуміти наявність проблеми, локалізувати її, і розуміти як її виправити З розуміти, що проблема зʼявилась і в чому вона полягає Швидко від реагувати

29. OBSERVABILITY Бізнесові метрики Здоровий сон не можливий без розуміння, що зараз відбувається * Інфраструктурні метрики Application (product) метрики Alert Логи Трасування

30. ФОРМУЛА СНУ

31. ВИСНОВКИ Формуйте процеси, що усувають невизначеність на кожному етапі розробки. Розробляйте тестову стратегію так, щоб кожна зміна викликала лише впевненість, а не страх. Забезпечуйте повну видимість роботи системи. Ідеального підходу немає. Є те, що ефективно працює у вас в конкретний момент часу. Поєднуйте інструменти та практики так, щоб компенсувати слабкі місця й підсилювати переваги одне одного.

32. Senior Backend Developer at TENTENS Tech LinkedIn: andrewyurchenko АНДРІЙ ЮРЧЕНКО