Эд Салливан - Время — деньги. Создание команды разработчиков программного обеспечения

• Определение целей и задач

Менеджер бета-тестирования должен следить за тем, что для программы бета-тестирования определены цели, профиль клиента, масштаб и продолжительность.

• Набор бета-тестеров

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

• Распространение ПО

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

• Распространение сведений о состоянии бета-тестирования

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

• Управление результатами бета-тестирования

От менеджера во многом зависит успех программы бета-тестирования. Почти сразу после её начала он должен обзвонить бета-тестеров, чтобы проверить, получили ли они ПО и, если да, начали ли работать с ним. Менеджер бета-тестирования должен следить за успехами каждого бета-тестера и обязательно стимулировать отстающих, чтобы они установили ПО и приступили к работе.

• Завершение программы бета-тестирования

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

• Поощрение бета-тестеров

Бета-тестеры — чрезвычайно ценные участники проекта. Хороших тестеров необходимо поощрять, плохих — исключать из программы.

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

Набор бета-тестеров требует времени, как и подписание соглашения о неразглашении коммерческой тайны. Набор непременно нужно начинать задолго до готовности бета-версии программы. Для программы, в которой участвует 200 бета-тестеров, я рекомендую оставлять 60-90 дней.

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

Как я говорил в главе 1, выпуск каждой бета-версии знаменует завершение крупного промежуточного этапа в работе над проектом. Таким образом, прежде чем рассылать бета-версию бета-тестерам, нужно завершить период стабилизации и интеграции. Этот период (обычно 1-2 недели) используется для тестирования, исправления ошибок и решения серьёзных проблем. Качество ПО должно быть достаточным для работы на местах бета-тестирования. До выпуска продукта во внешний мир надо подумать о проведении внутренних испытаний, о которых пойдёт речь в главе 14. Бета-версия — это ещё не окончательная версия ПО, однако изложенные в этой главе концепции помогут извлечь пользу даже из неё.

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

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

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

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

Вот и исправлена последняя ошибка — всё готово к окончательной сборке ПО, которая станет «кандидатом на выпуск, (relise candidate, RC). Хочется думать, что на этом этапе неприятностей уж точно не случится, однако вероятность возникновения серьёзных проблем все ещё велика. В конце концов, после выпуска с вашим ПО будут работать сотни, тысячи и даже миллионы пользователей. Можно ли быть заранее уверенным в готовности продукта? Как знать наверняка, что последний набор изменений не привёл к существенному падению производительности или что функцию, протестированную на прошлой неделе, не нарушили вчера или позавчера? Нельзя просто сидеть и надеяться, что всё идёт хорошо. Отзыв ПО из производства или из сети после того, как было публично объявлено о его выходе, чреват не только большими убытками, но и потерей репутации компании.