PMsoop: Глава №9: Что и как будем тестировать

В ролях – Менеджер Проекта, тестировщики, разработчики

Артефакты – ТЗ, task-list

Суть – Менеджер Проекта вместе с тестировщиками и разработчиками добавляет в таск-лист задачи тестирования

В этой главе рассмотрим следующую цель подготовительного этапа:

Цель 6. Наметить основные этапы и типы тестирования

Для реализации цели понадобится согласованный с разработчиками таск-лист. Менеджер Проекта собирает тестировщиков и они вместе определяют на каких этапах проекта понадобится тестирование и какое именно тестирование понадобится на этих этапах. После чего выделенные задачи тестирования добавляются в таск-лист.

Для начала кратко рассмотрим основные типы тестирования, применяемые для большинства проектов:

- функциональное тестирование (functional testing) – сверка реализованных функций с их поведением, описанным в ТЗ

- тестирование безопасности (security testing) – поиск способов “сломать” приложение, вводя нестанадртные данные, используя скрипты и т.п.

- тестирование интерфейса (usability testing) – проверка удобства работы с графическим инетрфейсом, поиск оптимизаций

- нагрузочное тестирование (performance testing) – проверка работы приложения под нагрузкой, определённой в нефункциональных требованиях ТЗ

- регрессионное тестирование (regression testing) – проверка работы функционала, реализованного в версиях 1 – N при тестировании версии N+1 (иногда новый код может “поломать” работу старого)

Вообще, типов тестирования выделяют более 20. Подробнее о них можно узнать в специальной литературе, Гугл в помощь. Какие именно типы тестирования могут понадобиться в конкретном проекте, Менеджер Проекта может определить с экспертом в области тестирования, если таковые есть в компании-Разработчике, до проведения собрания с тестировщиками.

Теперь перейдём к собранию с тестировщиками. Начать следует с определения, какие типы тестирования понадобятся для каждой версии, которая будет сдаваться Заказчику. Как минимум, в каждой версии надо проверять новый функционал, реализованный в данной версии, а также работу функционала реализованного ранее. Если дизайн интерфейса разрабатывается самостоятельно – стоит провести usability testing.

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

Особое внимание надо обратить на нагрузочное тестирование – его следует проводить как можно раньше. Низкое быстродействие приложения может потребовать серьёзных изменений в архитектуре, которые проще провести вначале проекта.

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

По результату обсуждений необходимо выделить и добавить в таск-лист задачи тестирования, такие как например “функциональное тестирование 1й версии”, “нагрузочное тестирование 2й версии” и т.п. Для каждой задачи, добавленной в таск-лист, нужно указать тип тестирования и роль, ответственную за данную задачу.

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

При выделении задач тестирования не стоит углубляться в детали реализации – как именно будет выполняться тестирование можно и нужно будет определить потом. Условие элементарности задачи можно сформулировать так: в рамках задачи выполняется тестирование одного типа, при этом выполнение задачи может быть проведено одним и тем же тестировщиком (или группой тестировщиков) без перехода к другим задачам.

Проверка достижения цели – задачи тестирования добавлены в таск-лист, порядок выполнения задач разработки и тестирования согласован и с разработчиками и с тестировщиками.