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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

К началу тестирования кандидата на выпуск все работы над продуктом (кроме собственно испытаний кандидата) должны быть закончены. Несмотря на это простое требование, всегда есть сильное искушение найти ещё несколько ошибок или внести изменения в программу и её документацию. Начав работу над кандидатом на выпуск, следует вести очень строгий контроль любых изменений. Не обманывайте себя, думая, что всё готово, когда на самом деле все наоборот. Чтобы внести ясность в этот вопрос, пройдёмся по основным требованиям, предъявляемым к кандидатам.

• Готовы все функции программы

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

• Справочные материалы приведены в окончательный вид

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

• Завершена последняя проверка пользовательского интерфейса

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

• Закончено тестирование программы

Группа выполнила план тестирования в полном объёме: проведено блочное, системное, нагрузочное тестирование, тестирование производительности и испытание пользовательского интерфейса, а также автоматизированное тестирование. Все тесты пройдены, по крайней мере, известны все неполадки и решено поставлять продукт, не устраняя их.

• Все ошибки исправлены

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

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

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