Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Lamoda Tech
September 24, 2024

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

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

Lamoda Tech

September 24, 2024
Tweet

More Decks by Lamoda Tech

Other Decks in Programming

Transcript

  1. Обо мне • 12 лет в тестировании • 5 лет

    в Lamoda Tech • сейчас занимаюсь организацией процессов тестирования бэкенда • в прошлом тестировал тренажер аварии на атомной АЭС
  2. 3 Как видят приложение разработчик и QA: искажения из-за разного

    восприятия 1 2 Как выстроить процесс тестирования на разных уровнях О чем сегодня поговорим:
  3. 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
  4. Manual Exploratory Tests End-to-end Tests Integration Tests Acceptance Tests –

    BDD Unit Tests – TDD Coverage Cost Testing pyramid
  5. 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
  6. 7

  7. К чему может привести разное видение подхода к тестированию: Ситуация

    Последствия • разработчик самостоятельно пишет все уровни тестов • смешение уровней тестирования, плохая читаемость • разработчик самостоятельно реализовал фреймворк тестирования • обилие велосипедов, сложность поддержки • QA не знает о тестах разработчика или не валидирует их • ложноположительные результаты и дублирующие тесты
  8. Если спросить трех разработчиков что такое unit-тесты, мы услышим три

    разных ответа. Функция, класс или небольшая группа классов — это юнит, и мы его тестируем. Unit-тесты Что такое unit-тесты?
  9. 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
  10. • Разработчик пишет код и сразу же тесты • Разработчик

    уверен в своем коде (предвзятость подтверждения и проклятие знания) • Разработчик пишет тесты как код • Границы теста могут выходит за пределы юнита • QA не валидирует такие тесты Unit-тесты: как что обычно происходит?
  11. Unit-тесты: рекомендации для QA Проверять покрытие бизнес правил этими тестами;

    1 2 3 Контролировать стиль написания тестов; Выровняться в терминах, что есть unit, интеграционное и end-to-end тестирование;
  12. Интеграционные тесты Интеграционные тесты проверяют взаимодействие между модулями или компонентами

    системы. Задача таких тестов – не проверка функциональности компонентов, собранных вместе, а проверка корректности точек интеграции и передачи данных между ними. Что такое интеграционный тест?
  13. 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
  14. • Разработчик не владеет всем необходимым бизнес-контекстом для написания тестов;

    • Разработчик уверен в своем коде (особенно при наличии спецификации); • QA не хватает экспертизы в разработке для внедрения фреймворка, подготовки тестовой среды и реализации вспомогательных утилит. Интеграционные тесты: что обычно происходит?
  15. Интеграционные тесты: рекомендации для QA В идеале QA проектирует и

    пишет интеграционные тесты; 1 2 Если QA не хватает экспертизы в разработке, то не стоит бояться обратиться к команде за помощью (внедрить фреймворк, вспомогательные утилиты, моки); 3 В крайнем случае, если их пишет разработчик, выстроить процесс ревью тестов с обязательным апрувом от QA.
  16. Фреймворк Gonkey — low-code фреймворк на Go Ссылка на GitHub

    • работает с REST/JSON API • тестирует API сервиса на соответствие спецификациям OpenAPI • заполняет базу данных данными фикстур (поддерживает PostgreSQL, MySQL, Aerospike, Redis) • предоставляет макеты для внешних сервисов • может использоваться как библиотека и запускаться вместе с модульными тестами • сохраняет результаты в виде отчета Allure
  17. 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
  18. End-to-end тесты: что обычно происходит? • Недостаток понимания архитектуру системы

    и следовательно границ тестирования; • Возникают сложности с выстраиванием тестовой инфраструктуры; • Нехватка бизнес-контекста и знаний системных сценариев • QA лучше других понимает как протестировать пользовательские сценарии • QA не хватает экспертизы в разработке для внедрения фреймворка автоматизации тестирования
  19. Управлять процессом end-to-end тестирования от начала и до конца; Вовлекать

    разработчиков во внедрение инструментов автоматизации тестирования; Вовлекать DevOps для выстраивания CI/CD; Консультироваться с системными аналитиками и архитекторами по вопросам поведения системы; End-to-end тесты: рекомендации для QA 1 2 3 4
  20. Unit tests Integration tests End- to-end tests Чем ниже мы

    по пирамиде: тем больше ответственности разработчика QA консультирует Чем выше мы по пирамиде: тем больше ответственности QA разработчик консультирует Выводы Abstract, general, rarely changes Concrete, specific, changes frequently Slow, $$$ Fast, $
  21. Q&A