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

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

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 специалисту полезно узнать еще на этапе подключения к проекту для своевременного понимания уровня зрелости процессов в команде. Таким образом, еще в процессе онбординга происходит определение:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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