В публикации рассмотрим общий флоу, конкретные нюансы и 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 специалисту полезно узнать еще на этапе подключения к проекту для своевременного понимания уровня зрелости процессов в команде. Таким образом, еще в процессе онбординга происходит определение:
доступов ко всем ресурсам проекта
состава и ролей команды
способов коммуникации внутри команды и между командами
расписания внутренних и межкомандных встреч или созвонов
мест хранения проектной документации
состава и назначения стендов
наличия расписания релизов
-
существующих выстроенных на проекте процессов
наличия статусов и переходов между ними для тасок/дефектов/тест-кейсов/инцидентов/сторей/эпиков в таск-трекере для каждой роли в команде
ведения тестовой документации, наличия шаблонов документов
прохождения тест-кейсов
работы с инцидентами
составления отчетов
наличия инструментов визуализации данных для просмотра логов или мониторинга
наличия дашбордов
наличие метрик тестирования
Заключение
Прежде чем внедрять новые изменения, важно понять, какие процессы уже выстроены в компании. И отталкиваясь от этого, начать улучшать и менять текущую ситуацию. По шагам, исправляя одну проблему за другой, начиная с самых важных и не накидываясь на всё разом.
Надеюсь статья была полезной и дала пищу для размышления. Спасибо за внимание!