PMsoop: Глава №21: Тестирование и исправление дефектов

В ролях – Менеджер Проекта, команда проекта

Артефакты – требования, план тестирования, issues

Суть – Устранение выявленных дефектов

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

1. Хорошо, когда есть план тестирования, в котором описаны какие виды тестирования надо применять и как именно это делать. Про план тестирования я уже писал в предыдущих главах. Основная польза от такого плана – «прозрачность» текущего состояния тестирования для менеджера проекта, удобство в планировании сроков и трудозатрат.

2. Важной штукой является среда учёта дефектов a-la Jira. Когда все дефекты собраны в одном месте, с проставленными статусами и указанием ответственных за них тестировщиков и разработчиков – это реально удобно.Время, потраченное на установку такой среды, с лихвой компенсируется временем, сэкономленным при поиске информации по дефекту и уточнении этой информацией, кроме того нервы тоже надо экономить. Чем прозрачнее процесс – тем проще жить всем его участникам.

3. В любом случае, какую бы среду учёта дефектов вы не использовали, описание дефекта должно содержать следующую информацию:

a. Кто обнаружил дефект

b. С какой функцией связан дефект (ссылка на раздел требований)

c. Описание шагов воспроизведения дефекта

d. Скриншот ошибки – желательно

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

5. Тестирование и устранение дефектов следует вести в виде под-итераци. А именно:

a. Некоторое время идёт тестирование, затем тестировщики представляют сводный список дефектов.

b. Тестирование останавливается, разработчики устраняют дефекты и готовят новую версию

c. К новой версии неплохо бы обновить release notes – добавить информацию о том какие именно дефекты устранены в этой новой версии

d. Новая версия отдаётся снова в тестирование

e. См. П. а

6. При получении списка дефектов обязательным действием является приоретизация этого списка. А именно, менеджер проекта или ведущий тестировщик должны обозначить в явном виде степень критичности каждого дефекта и очередность его устранения для разработки.

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

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

9. По завершению тестирования следует провести собрание с командой проекта с целью обсудить и утвердить готовность версии к сдаче Заказчику. Только после этого, когда ни у кого нет возражений, версия готова к сдаче.