Делим тесты между QA и разработчиком

Подходы в тестировании во многом уже устоялись, но есть еще вопросы, на которые можно дискутировать и искать правильные для себя ответы. Где лежит граница ответственности в тестировании между тестировщиком и разработчиком? Нужно ли QA проверять автотесты, которые пишет разработчик? И на чью сторону перелетает мяч в зависимости от разных этапов тестирования? В докладе Кирилл рассказал про нюансы в выстраивании стратегии на разных уровнях тестирования, и о том, как QA-инженер может улучшить процесс проверки кода.

Transcript

1. Кирилл Поляков Ведущий инженер по тестированию Делим тесты между QA и разработчиком
2. Обо мне • 12 лет в тестировании • 5 лет в Lamoda Tech • сейчас занимаюсь организацией процессов тестирования бэкенда • в прошлом тестировал тренажер аварии на атомной АЭС
3. 3 Как видят приложение разработчик и QA: искажения из-за разного восприятия 1 2 Как выстроить процесс тестирования на разных уровнях О чем сегодня поговорим:
4. Clean Architecture a.k.a unclebob’s style Network Devices DB … + Entities Use Cases JOBS REST APIs Core: business logic Entrypoints: access to the application Data Providers: retrieve and store information Configuration: wires everything together Configuration
5. Manual Exploratory Tests End-to-end Tests Integration Tests Acceptance Tests – BDD Unit Tests – TDD Coverage Cost Testing pyramid
6. Abstract, general, rarely changes Unit tests Integration tests End-to end tests Entities Use Cases Controllers Gateways Presenters Devices DB External Interfaces Web UI Concrete, specific, changes frequently Clean Architecture pyramid Testing pyramid
8. К чему может привести разное видение подхода к тестированию: Ситуация Последствия • разработчик самостоятельно пишет все уровни тестов • смешение уровней тестирования, плохая читаемость • разработчик самостоятельно реализовал фреймворк тестирования • обилие велосипедов, сложность поддержки • QA не знает о тестах разработчика или не валидирует их • ложноположительные результаты и дублирующие тесты
9. Первый уровень тестирования
10. Если спросить трех разработчиков что такое unit-тесты, мы услышим три разных ответа. Функция, класс или небольшая группа классов — это юнит, и мы его тестируем. Unit-тесты Что такое unit-тесты?
11. unit tests Billing Service User Service User Repository DB Connection Interface HTTP Handler HTTP Server Interface our class we want to test mock implementation out of scope for test
12. Unit-тесты Кто пишет: разработчик
13. • Разработчик пишет код и сразу же тесты • Разработчик уверен в своем коде (предвзятость подтверждения и проклятие знания) • Разработчик пишет тесты как код • Границы теста могут выходит за пределы юнита • QA не валидирует такие тесты Unit-тесты: как что обычно происходит?
14. Unit-тесты: рекомендации для QA Проверять покрытие бизнес правил этими тестами; 1 2 3 Контролировать стиль написания тестов; Выровняться в терминах, что есть unit, интеграционное и end-to-end тестирование;
15. Второй уровень тестирования
16. «Целое больше суммы своих частей» (с) Аристотель Интеграционные тесты
17. Интеграционные тесты Интеграционные тесты проверяют взаимодействие между модулями или компонентами системы. Задача таких тестов – не проверка функциональности компонентов, собранных вместе, а проверка корректности точек интеграции и передачи данных между ними. Что такое интеграционный тест?
18. integration tests Billing Service User Service User Repository DB Connection Interface HTTP Handler HTTP Server Interface our class we want to test test interaction with dependency mock implementation out of scope for test
19. Интеграционные тесты Кто пишет: QA или разработчик*
20. • Разработчик не владеет всем необходимым бизнес-контекстом для написания тестов; • Разработчик уверен в своем коде (особенно при наличии спецификации); • QA не хватает экспертизы в разработке для внедрения фреймворка, подготовки тестовой среды и реализации вспомогательных утилит. Интеграционные тесты: что обычно происходит?
21. Интеграционные тесты: рекомендации для QA В идеале QA проектирует и пишет интеграционные тесты; 1 2 Если QA не хватает экспертизы в разработке, то не стоит бояться обратиться к команде за помощью (внедрить фреймворк, вспомогательные утилиты, моки); 3 В крайнем случае, если их пишет разработчик, выстроить процесс ревью тестов с обязательным апрувом от QA.
22. Фреймворк Gonkey — low-code фреймворк на Go Ссылка на GitHub • работает с REST/JSON API • тестирует API сервиса на соответствие спецификациям OpenAPI • заполняет базу данных данными фикстур (поддерживает PostgreSQL, MySQL, Aerospike, Redis) • предоставляет макеты для внешних сервисов • может использоваться как библиотека и запускаться вместе с модульными тестами • сохраняет результаты в виде отчета Allure
23. Третий уровень тестирования
24. Тесты, которые тестируют всю систему целиком, от начала до конца. End-to-end тесты Что такое end-to-end тесты?
25. system tests Billing Service gRPC User Service User Repository DB Connection Interface HTTP Handler HTTP Server Interface our class we want to test test interaction with dependency
26. Кто пишет: QA End-to-end тесты
27. End-to-end тесты: что обычно происходит? • Недостаток понимания архитектуру системы и следовательно границ тестирования; • Возникают сложности с выстраиванием тестовой инфраструктуры; • Нехватка бизнес-контекста и знаний системных сценариев • QA лучше других понимает как протестировать пользовательские сценарии • QA не хватает экспертизы в разработке для внедрения фреймворка автоматизации тестирования
28. Управлять процессом end-to-end тестирования от начала и до конца; Вовлекать разработчиков во внедрение инструментов автоматизации тестирования; Вовлекать DevOps для выстраивания CI/CD; Консультироваться с системными аналитиками и архитекторами по вопросам поведения системы; End-to-end тесты: рекомендации для QA 1 2 3 4
29. Unit tests Integration tests End- to-end tests Чем ниже мы по пирамиде: тем больше ответственности разработчика QA консультирует Чем выше мы по пирамиде: тем больше ответственности QA разработчик консультирует Выводы Abstract, general, rarely changes Concrete, specific, changes frequently Slow, $$$ Fast, $
30. Q&A