Lviv Quality Assurance Day 2019 ОЛЕГ ЗАРЕВИЧ «How did we improve delivery using tests» Telegram: www.t.me/goqameetup Facebook: www.fb.com/goqaevent Linkedin: www.linkedin.com/company/goqa/ Сайт: www.qaday.org

1. How did we improve delivery
using tests

2. • Senior AQA @ Intellias
• В тестуванні з 2012
• Більше 5 років займаюсь
автоматизацією тестування
• «За дотнет і двор стріляю в
упор»
• багаторазовий учасник
проекту «то не баг» та «там
лише один рядочок
помінявся»

3. Ця доповідь буде …
• Набір проблем типових програмних проектів
• Залежати від контексту
• Може допомогти вашому проекту...
• ...але це не точно
• Потрібно бути готовим до змін

4. Що таке “якісний” продукт
• Виконує те, що очікує користувач
• Дешевий у підтримці
• Легко і часто постачаються нові версії

5. Як виглядає типовий проект
• Веб продукт
• Одна або декілька функціональних команд (DEVs +
QAs)
• AQA команда, відділена від функціональних
команд
• Регресія займає довгий час

6. Типові проблеми
• Складні релізи
• Проблеми на продакшені
• Час на фікси продакшена зменшують час на роботу
в ітерації
• Ціна підтримки росте експоненціально
• Важко масштабувати монолітні аплікації

7. Microservices

9. Цілі для нового проекту
• Continuous delivery
• Високий рівень якості
• Масштабованість

10. Що потрібно, для досягнення цілей
• Аналіз та декомпозиція user stories
• Тісна співпраця між учасниками команди
• Тестування на різних рівнях
• Швидкий і легкий зворотній звязок від
автоматизованих тестів
• Жорстке дотримання правил

11. Unit tests
• Відповідальність інженерів, котрі розробляють код
• Націлені на побудову “захисної мережі”
• Превентивне виявлення помилки

12. Недоліки unit тестів
•Базуються на реалізації
•Підтримка може вимагати значний час, при
рефакторингу

13. Contract tests
• Consumer-Driven Contracts
• Превентивне виявлення проблеми інтеграції

15. Недоліки contract тестів
• Немає підтримки асинхронних контрактів
(принаймні для Pact .Net)
• Менше переваг в архітектурі з оркестратором
• Контракт для провайдера повинен бути швидше
ніж для споживача

16. Service Component Integration tests
• Тестують сервіс як black gray box
• Націлені на перевірку інтеграції сервісу з 3rd
ресурсами ( БД, черги, etc)
• Повинні бути швидкими

17. Недоліки Service tests
• Залежать від даних
• Залежать від зовнішніх ресурсів
• Важко налаштувати розробників на написання

18. System tests

19. API tests
• Перевіряють перевірку системи в цілому
• Покривають комбінації вхідних даних
• Швидкі

20. UI tests
• Покривають бізнес сценарії, а не user story
• Покривають якнайбільше UI елементів для
сценарія
• Мінімальна кількість
• Стабільні на 99%

21. Delivery pipeline

22. Що ми отримали в результаті
• К-сть закритих stories зменшилась
• Але їхня якіcть збільшилась
• Мінімум багів
• Дефекти в основному нетривіальні

23. Типові відмазки від змін
• “У нас складний проект, у нас так не можна”
• “Так історично склалось”
• “Давайте, ми спочатку зробимо, а тести напишемо
після релізу”
• “Процеси у нас не такі”

24. Як це застосувати в себе
• Застосовувати практики для вирішення проблеми
• Шукати причину проблеми, а не вирішувати симптоми
• Тісна співпраця всередині команди
• Готовність до змін та обміну обов’язками
• Почати писати юніт тести хоча би для нового функціоналу
• Автоматизовувати рутину