Процесс тестирования. Часть 4: Анализ результатов, репортинг и завершение тестирования

В процессе выполнения тестирования мы постоянно сталкиваемся с вопросами «Когда можно закончить тестировать?» и «Что делать дальше?» Сегодня мы поговорим о стадиях процесса тестирования, которые помогут нам ответить на эти вопросы.

Если вы не знакомы с фундаментальным процессом тестирования, то рекомендуем начать с первой части:

Фундаментальный процесс тестирования. Часть 1: Планирование и контроль тестирования

Анализ результатов, оценка критериев окончания тестирования и репортинг (Evaluating exit criteria and reporting)

Как мы уже знаем, задача мониторинга и контроля тестирования — это постоянный анализ всех активностей тестирования. Стадия анализа критериев окончания тестирования и репортинг является финальным аккордом этого процесса. Именно тут мы понимаем, что протестировали достаточно и можем отдавать продукт в релиз.

Эта активность выполняются вместе с активности по выполнению тестирования (Test Execution), как видно на изображении снизу:

Критерии окончания тестирования (exit criteria) — Набор активностей и критериев, согласованных со всеми заинтересованными лицами на этапе планирования тестирования, которые должны быть сделаны, чтобы считать процесс тестирования законченным.

На этапе анализа критериев окончания тестирования и репортинга могут выполняться следующие активности:

• Убедиться, что критерии окончания тестирования и метрики, определённые в тест-плане имеют достаточные показатели, например:
  • Все исправленные дефекты были протестированы повторно
  • Проектные метрики:
    • Executed tests = 100% — все запланированные тесты выполнены
  • Продуктовые метрики:
    • Passed test cases percentage > 80% — Больше 80% тестов должны быть пройдены успешно
    • Number of critical defects = 0 — Нет открытых дефектов с критичностью (Severity) Critical
    • Number of major defects = 0 — Нет открытых дефектов с критичностью (Severity) Major
• Отправить отчёт о результатах тестирования.

После завершения этих активностей мы переходим к следующей фазе процесса тестирования.

Завершение тестирования (Test closure activities)

В рамках активностей по завершению тестирования, мы собираем данные из всех активностей по тестированию и анализируем полученный опыт. Мы можем выполнять эти активности уже после релиза продукта.

Обычно активности по завершению тестированию состоят из следующих задач:

1. Проверка завершения тестирования — убедиться в том, что все запланированные активности по тестированию действительно завершены. Если в продукте остались незакрытые дефекты, то они должны быть определены как известные дефекты (Known issues), чтобы все заинтересованные лица знали об этих дефектах. Помимо этого может быть определено в каком следующем релизе эти дефекты будут исправлены.
2. Архивирование артефактов тестирования — убедиться в том, что всё что было сделано в рамках процесса тестирования тест-план, тесты, автотесты, окружение, баг-репорты и тд не будут утеряны и могут быть использованы в будущем вами, либо другой командой.
3. Накопленный опыт — участие во всех ретроспективных встречах должно быть задокументировано для того, чтобы закрепить и повторно использовать позитивный опыт и избежать негативного в будущем. Какие вопросы можно рассматривать на этом этапе:
   1. Были ли оценки на тестирование точными?
   2. В каких областях продукта больше всего концентрировались дефекты?
   3. Какие были причины возникновения дефектов?
   4. Были ли поздние баги?
   5. Если были проблемы со сроками, то из-за каких причин?
   6. Какие новые риски мы можем выделить?
   7. Были ли в плане неожиданные изменения, которые нужно учитывать при следующем планировании?
   8. Существуют ли другие потенциальные возможности улучшения процессов?
4. Передача артефактов тестирования — Если в организации есть команда, которая занимается поддержкой, то мы должны передать артефакты тестирования этим людям. Например, список известных дефектов, которые есть в релизной версии, информацию по развёртыванию (Deployment), ручные и автоматизированные тесты для прохождения регрессионного тестирования в период поддержки и тд.

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

На этом мы заканчиваем серию статей про фундаментальный процесс тестирования.

Выводы:

• Все описанные стадии процесса тестирования нужны для того, чтобы тестирование с большей вероятностью от релиза к релизу было качественным. По сути, это как рецепт нашего тестирования.
• Мы можем выполнять активности из разных стадий одновременно. Например, тест дизайн, выбор тестов и их выполнение.
• Все фазы процесса тестирования актуальны для любых методологий разработки ПО.