Lviv Direction QADay 2023 (automation) ОЛЕГ ЗАРЕВИЧ «Shift left та Shift Right підходи до тестування» telegram: wwww.t.me/goqameetup fb: www.fb.com/goqaevent fb: www.fb.com/qaday.org linkedin: https://www.linkedin.com/company/goqa/ Сайт: www.qaday.org

1. Shift left та Shift Right підходи
до тестування

2. Який настрій у вас ?
1 2
3

3. • Олег Заревич
• DevOps SRE engineer
• В тестуванні з 2012
• Більше 5 років займався
автоматизацією
• Фанат Microsoft стеку
• Ментор та спікер
• Пишу тут
https://medium.com/@olegzarevych

4. Тестування в SLDC

5. Проблема
• Довгий зворотній зв’язок
• Призводить до збільшення ціни
• Уповільнює реліз

6. Антипатерни
• Нічний запуск тестів
• Ручні регресії довжиною у вічність

8. Shift Left testing
• Shift Left – підхід у якому ми зміщуємо тестування у сторону
розробки та дизайну
• Приципи:
• Testability in mind
• Фокус на автоматизацію
• Швидке та часте виконання тестів
• Починаємо з низу тестової піраміди

9. Види тестів
• Static code analysis – Sonar, PMD, FindBug
• UnitIntegration tests
• Contract tests – pact.io
• E2E test – API, UI
• Security tests
• Compliance tests

10. Quality gates
• Запуск на машині розробника
• IDE
• Pre-commit hook
• Запуск на CI
• При створенні PR чи вітки

11. E2E tests in Shift left
• Тести повинні бути стабільними
• Повинні швидко виконуватись
• Запуск з однієї команди
• Не повинні залежати від тестових даних

12. Security testing
• Автоматизація базових перевірок безпеки
• Dependency scanning
• Security testing automation – BDD security, Gauntlt

13. Compliance testing
• Перевірка інфраструктури на відповідність стандартам
• Docker image scanning – Clair, Container Structure Tests
• Infrastructure tests – terratest

14. Shift Right testing
• Shift Right – зміщення тестування після деплоя на продакшин
• Але не обов’язково що саме на продакшин
• Аксіома - Ваша система впаде у продакшені
• Ціль – бути до того готовим та швидко реагувати

15. Smoke testing on prod
• Маленький набір тестів
• Тести повинні покривати основні бізнес сценарії
• Стабільні та швидкі

16. APM & Monitoring
• Отримувати дані про стан системи – Response time, error rate
• Бачити стан hardware – CPU, memory, networking
• Бізнес метрики
• Трейсинг помилок та збір логів
• Нотифікації про проблеми
• Tools – Prometheus, Datadog, Dynatrace
• Tracing – AppInsight, ELK, Jaeger

17. Synthetics checks
• Synthetic API monitoring
• Real User Monitoring
• Отримуємо доступність сервісу
• Отримуємо повідомлення коли щось йде не так
• Tools – Postman, Pingdom, Datadog

18. Canary releases
• Техніка розгортання сервісу,
коли доступ до нової версії
отримує певний %
користувачів
• Після певного часу, по
відсутності помилок, доступ
отримують більше або всі
користувачі
• Легко відкотитись назад

19. Chaos engineering
• Виконується на продакшині
• Моделюється проблема
• Повне завантаження CPU чи memory
• Зупинка сервісу
• Аналізуємо бізнес метрики
• Результат – мінімізуємо зону ураження
• Tools – Gremlin, Chaos Monkey

20. Summary
• Всі практики та підходи залежать від контексту
• Shift Left & Shift Right – це не ціль, а шлях
• Якість – командна відповідальність
• Не обовязково реалізовувати підхід, достатньо його
запропонувати