Как выстроить процессы тестирования на проекте

В публикации рассмотрим общий флоу, конкретные нюансы и best practices построения ручного процесса тестирования на проекте в agile методологии. Статья может быть полезна как для команд, которые только стартуют, так и для тех, кто уже некоторое время развивается, и где присутствуют проблемы с качеством. 

 Общий QA флоу

 Общий QA флоу

1. Инициализация

Вначале QA специалисту нужно понять и оценить задачи, их объем, сформировать подход к тестированию. Для этого он собирает всю необходимую информацию. При необходимости устраивает личные встречи с членами команды или организовывает общий груминг, на котором:

  • обозначается возможное влияние на смежные компоненты

  • устанавливается примерный регрессионный скоуп

  • оценивается полнота и корректность плана разработки

  • анализируются риски

Также на этом этапе выясняются цели и бизнес‑ценность разработки фичи или проекта, и дается предварительная оценка задачи, которая включает в себя время на анализ и тестирование документации, составление тест‑кейсов, подготовку тестовых данных, непосредственно тестирование, включая регрессию, и формирование отчетов.

2. Анализ требований и составление тестовой документации

QA инженером проводится анализ и тестирование требований, технических спецификаций и макетов.

  • Определяется наличие критериев готовности артефакта к передаче в разработку (DoR) и к передаче в эксплуатацию конечным пользователям (DoD).

  • Формируется матрица соответствия критериям качественных требований.

  • Определяются зависимости от внешних команд и систем.

  • Обозначаются вопросы и заводится чек‑лист, в котором пишутся и приоритезируются высокоуровневые тестовые сценарии.

  • Тест‑сценарии проходят ревью с аналитиками/дизайнерами и разработчиками, а также при необходимости и другими членами QA команды.

  • После успешного прохождения ревью высокоуровневые тест-сценарии переводятся в полноценные тест-кейсы в соответствии с внутренними правилами их оформления и отбираются для дальнейших регрессионных/смоук/E2E скоупов. При необходимости тест-кейсы также добавляются в соответствующие наборы для автоматизации тестирования.

  • При нахождении дефектов в процессе тестирования документации на дизайнера или аналитика QA инженером заводится баг, либо задача на доработку требований с соответствующей пометкой. 

  • Проводится проверка внесенных изменений дизайнером или аналитиком.

  • Проверяется наличие всех необходимых доступов.

  • По возможности заранее подготавливаются тестовые данные.

3. Планирование

Время для общих планингов, на которых определяется или актуализируется:

  • расписание и сроки релизов,

  • приоритеты задач,

  • приоритеты тест-кейсов,

  • приоритеты дефектов.

В зависимости от целей в случае перепланирования приоритеты задач и тест-кейсов могут быть пересмотрены. При наличии сжатых сроков возможно выполнение только тест-кейсов с высоким приоритетом. 

При этом задачи распределяются по QA команде с учетом равномерной нагрузки на каждого специалиста.

4. Выполнение

На данном этапе Тестировщик проходит шаги, описанные в документации. При необходимости актуализируя / дополняя тест-кейсы, а также смоук, регресс и E2E наборы. 

Фиксировать следует каждый дефект (даже если разраб при вас пофиксил его за 5 минут) для отслеживания метрик с отражением в дефекте максимального количества информации (логи, версии сборок, скриншоты и тд). Не лишним также будет слинковать его дополнительно с соответствующей UserStory или задачей на разработку. 

После каждого прохождения тест-кейса или проверки багфикса прикладывается Proof of Testing, в котором присутствуют:

  • Статус (Passed/Failed)

  • Ожидаемый и фактический результат (если кейс пройден ОР=ФР)

  • Версия сборки

  • Окружение

  • Скриншот или запись экрана

  • Браузер/ОС

Также на данном этапе проверяется и фиксируется соответствие ранее установленным критериям успешности, например:

  • Выполнено 100% из запланированных тест-кейсов

  • Пройдено (Passed) 90% тест-кейсов

  • Исправлены все дефекты с высоким приоритетом (100%)

Кроме того, при прохождении кейсов приветствуется написание любых инструкций, которые облегчат тестирование в будущем. Например, инструкция по авторизации для апи методов через постман, руководство по просмотру и анализу логов или шаблон описания дефекта.

Также важно не забывать о том, чтобы в каждый момент времени в таск или баг трекере статус и исполнитель любой сущности были актуальными.

5. Завершение

На данном этапе QA инженер проводит регрессионное тестирование релиза на stage/препрод окружении. 

После успешного прохождения регресса релиз выкатывается на прод, где проходит смоук тестирование.

Для удобства отслеживания дефектам, найденным в регрессе/смоке, проставляется специальная метка с названием сервиса, соответствующего скоупа и версией сборки, в которой он был найден. 

QA инженер также должен предусмотреть версионирование тест-кейсов в зависимости от версии релиза для отслеживания статусов прохождения кейсов в каждом релизе. Например, в confluence/excel создается страница с эталонным скоупом тестов, которая при каждом прохождении копируется и при необходимости дополняется или редактируется, либо для этого используются специальные плагины/сервисы. 

Далее Тестировщик формирует отчет о статусе релиза, в котором может находиться:

  • список задач/сторей/любых изменений 

  • список тест-кейсов

  • список дефектов высокого приоритета, найденных и/или исправленных в текущем релизе

  • метрики (кол-во и процент выполненных/пройденных/не пройденных тест-кейсов для регрессии/смока/фича-тестов)

  • в явном виде подтверждение/не подтверждение для выхода в прод со стороны QA

  • диаграммы и любая другая дополнительная информация

Дополнительно выделим ряд пунктов, которые QA специалисту полезно узнать еще на этапе подключения к проекту для своевременного понимания уровня зрелости процессов в команде. Таким образом, еще в процессе онбординга происходит определение:

  • доступов ко всем ресурсам проекта

  • состава и ролей команды

  • способов коммуникации внутри команды и между командами

  • расписания внутренних и межкомандных встреч или созвонов

  • мест хранения проектной документации

  • состава и назначения стендов

  • наличия расписания релизов

  • существующих выстроенных на проекте процессов

    • наличия статусов и переходов между ними для тасок/дефектов/тест-кейсов/инцидентов/сторей/эпиков в таск-трекере для каждой роли в команде

    • ведения тестовой документации, наличия шаблонов документов

    • прохождения тест-кейсов

    • работы с инцидентами

    • составления отчетов

  • наличия инструментов визуализации данных для просмотра логов или мониторинга

  • наличия дашбордов

  • наличие метрик тестирования

Заключение

Прежде чем внедрять новые изменения, важно понять, какие процессы уже выстроены в компании. И отталкиваясь от этого, начать улучшать и менять текущую ситуацию. По шагам, исправляя одну проблему за другой, начиная с самых важных и не накидываясь на всё разом. 

Надеюсь статья была полезной и дала пищу для размышления. Спасибо за внимание!

© Habrahabr.ru