PMsoop: Глава №20: Подготовка к сдаче версии в тестирование

В ролях - Менеджер Проекта, команда проекта Артефакты – план проекта, требования, release notes Суть – проверка готовности к сдаче версии в тестирование Предположим, в рамках версии предполагалось воплотить 10 функций/фич (features). Разработчики сообщают менеджеру проекта, что все сделано. Что дальше?

В первую очередь, нужно чтобы разработчики сами проверили что написанный код работает и заявленные требования реализованы в полном объёме. Большим подспорьем в этом деле является использование Unit Tests в разработке. Успешное прохождение всех Unit Tests обычно показывает что «всё хорошо». Если юнит-тестирование в разработке не применялось (или применялось только частично) – рекомендую менеджеру проекта поставить задачу ведущим разработчикам лично ещё раз перепроверить написанный код и соответствие сделанного требованиям.

Следующим рекомендуемым шагом является проверка реализованного функционала самим менеджером проекта. Задача проста – открыть приложение и «пробежаться» по функционалу. Основное внимание следует обращать на соответствие сделанного требованиям версии и отсутствие критических ошибок. Нужно это для страховки от невнимательности разработчиков – а это нередкое явление, разработчики работают с приложением ежедневно и могут какие-то моменты просто незамечать или считать чужой зоной ответственности.

Если всё ок, и на первый взгляд всё работает в соотвествтии с требованиями – перехлодим к шагу «пишем Release Notes». Release Notes – это такой документ, в котором кратко перечислен функционал реализованный в рамках текущей версии (и предыдущих тоже), отмечены известные недостатки (на ранних версиях бывают баги и нерабочий функционал, которые не затрагивает ключевые функции этой версии но могут вызвать вопросы у тестировщиков), указаны разработчики ответственные за каждую функцию. Задача этого документа – дать тестировщикам понимание что тестировать, а на что не обращать внимание, и к кому обращаться за пояснениями или кого ставить ответственным за исправление дефекта. Кроме этого, Release Notes может содержать массу дополнительной информации, как то:

· спецификация среды запуска

· перечень используемых сторонних компонент

· руководства по установке приложения

· help, FAQ

Формат документа Release Notes бывает разным. Примеры:

http://www.mozilla.com/en-US/firefox/3.6/releasenotes/

http://readyset.tigris.org/nonav/templates/release-notes.html

Написание Release Notes редко занимает более часа, сделать это может сам менеджер проекта, или аналитик, или ведущий разработчик. Использование этого документа экономит не только время на выяснение «что сделано» между тестироващиками и разработчиками, но и нервы (что немаловажно с точки зрения нормальных отношений в проектной команде). Так что, рекомендую.

После того, как новая версия проверена у разработчиков и менеджером проекта, и написаны release notes – можно «отдавать» версию в тестирование. В зависимости от того, что и как вы разрабатываете, процедура передачи может быть разной. Например:

· дать доступ к папке с готовым инсталлируемым приложением

· поставить приложение на выделенный сервер тестирования (требует привлечения либо разработчиков либо админа проекта)

· дать доступ к серверу разработки тестировщикам (если для тестирования не сипользуется выделенная среда)

· отправить код и инструкции по установке группе тестирования (если тестированием занимается отдельная команда и установку они производят сами, не забудьте написать инструкции…)

В любом случае, на забудьте приложить Release Notes