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
2. • Senior AQA @ Intellias
• В тестуванні з 2012
• Більше 5 років займаюсь
автоматизацією тестування
• «За дотнет і двор стріляю в
упор»
• багаторазовий учасник
проекту «то не баг» та «там
лише один рядочок
помінявся»
3. Ця доповідь буде …
• Набір проблем типових програмних проектів
• Залежати від контексту
• Може допомогти вашому проекту...
• ...але це не точно
• Потрібно бути готовим до змін
4. Що таке “якісний” продукт
• Виконує те, що очікує користувач
• Дешевий у підтримці
• Легко і часто постачаються нові версії
5. Як виглядає типовий проект
• Веб продукт
• Одна або декілька функціональних команд (DEVs +
QAs)
• AQA команда, відділена від функціональних
команд
• Регресія займає довгий час
6. Типові проблеми
• Складні релізи
• Проблеми на продакшені
• Час на фікси продакшена зменшують час на роботу
в ітерації
• Ціна підтримки росте експоненціально
• Важко масштабувати монолітні аплікації
9. Цілі для нового проекту
• Continuous delivery
• Високий рівень якості
• Масштабованість
10. Що потрібно, для досягнення цілей
• Аналіз та декомпозиція user stories
• Тісна співпраця між учасниками команди
• Тестування на різних рівнях
• Швидкий і легкий зворотній звязок від
автоматизованих тестів
• Жорстке дотримання правил
11. Unit tests
• Відповідальність інженерів, котрі розробляють код
• Націлені на побудову “захисної мережі”
• Превентивне виявлення помилки
15. Недоліки contract тестів
• Немає підтримки асинхронних контрактів
(принаймні для Pact .Net)
• Менше переваг в архітектурі з оркестратором
• Контракт для провайдера повинен бути швидше
ніж для споживача
16. Service Component Integration tests
• Тестують сервіс як black gray box
• Націлені на перевірку інтеграції сервісу з 3rd
ресурсами ( БД, черги, etc)
• Повинні бути швидкими
17. Недоліки Service tests
• Залежать від даних
• Залежать від зовнішніх ресурсів
• Важко налаштувати розробників на написання
19. API tests
• Перевіряють перевірку системи в цілому
• Покривають комбінації вхідних даних
• Швидкі
20. UI tests
• Покривають бізнес сценарії, а не user story
• Покривають якнайбільше UI елементів для
сценарія
• Мінімальна кількість
• Стабільні на 99%
22. Що ми отримали в результаті
• К-сть закритих stories зменшилась
• Але їхня якіcть збільшилась
• Мінімум багів
• Дефекти в основному нетривіальні
23. Типові відмазки від змін
• “У нас складний проект, у нас так не можна”
• “Так історично склалось”
• “Давайте, ми спочатку зробимо, а тести напишемо
після релізу”
• “Процеси у нас не такі”
24. Як це застосувати в себе
• Застосовувати практики для вирішення проблеми
• Шукати причину проблеми, а не вирішувати симптоми
• Тісна співпраця всередині команди
• Готовність до змін та обміну обов’язками
• Почати писати юніт тести хоча би для нового функціоналу
• Автоматизовувати рутину