тестерам, нужно завершить период стабилизации и интеграции. Этот период (обычно 1-2 недели) используется для тестирования, исправления ошибок и решения серьёзных проблем. Качество ПО должно быть достаточным для работы на местах бета-тестирования. До выпуска продукта во внешний мир надо подумать о проведении внутренних испытаний, о которых пойдёт речь в главе 14. Бета-версия — это ещё не окончательная версия ПО, однако изложенные в этой главе концепции помогут извлечь пользу даже из неё.
Для нормального проведения бета-тестирования нужна подходящая программная и аппаратная инфраструктура. Скажем, для управления поступающей от бета-тестеров информацией, статусом соглашений о неразглашении коммерческой тайны, оценки работы бета-тестеров скорее всего потребуется специальная программа. Нельзя недооценивать объём информации, с которым придётся работать.
Самой большую пользу от бета-тестирования представляет информация, которую оно позволяет получить. Процедуры передачи, обработки и продвижения информации должны быть чёткими и понятными. Для поддержки бета-тестирования обязательно нужны компетентные и хорошо обученные специалисты. Также необходимо оставаться в контакте с бета-тестерами в течение всего процесса бета- тестирования.
Для бета-тестирования должно быть выделено достаточно времени. Начав его в понедельник, не надейтесь закончить его в пятницу, если рассчитываете на хорошие результаты.
Как я уже говорил, ценность программы бета-тестирования определяется числом отзывов, которые она помогает собрать. Если отзывов слишком мало, нужно собрать их. Звоните и спрашивайте, установили ли тестеры программу и успешно ли они с ней работают. Пишите по электронной почте, чтобы убедиться, что у всех бета-тестеров всё идёт нормально. Анкеты также помогают собрать сведения, позволяющие решать проблемы и следить, чтобы реализация проекта шла по намеченному пути.
Глава 14
Кандидат на выпуск
Вот и исправлена последняя ошибка — всё готово к окончательной сборке ПО, которая станет «кандидатом на выпуск, (relise candidate, RC). Хочется думать, что на этом этапе неприятностей уж точно не случится, однако вероятность возникновения серьёзных проблем все ещё велика. В конце концов, после выпуска с вашим ПО будут работать сотни, тысячи и даже миллионы пользователей. Можно ли быть заранее уверенным в готовности продукта? Как знать наверняка, что последний набор изменений не привёл к существенному падению производительности или что функцию, протестированную на прошлой неделе, не нарушили вчера или позавчера? Нельзя просто сидеть и надеяться, что всё идёт хорошо. Отзыв ПО из производства или из сети после того, как было публично объявлено о его выходе, чреват не только большими убытками, но и потерей репутации компании.
При работе над кандидатом на выпуск проводится систематическая и объективная проверка окончательной сборки программного продукта, чтобы выяснить, готова ли она к выходу. В этой главе будут раскрыты базовые принципы организации работы над кандидатами на выпуск, преследующей цель подготовки ПО к выходу во внешний мир.
Начальные требования
К началу тестирования кандидата на выпуск все работы над продуктом (кроме собственно испытаний кандидата) должны быть закончены. Несмотря на это простое требование, всегда есть сильное искушение найти ещё несколько ошибок или внести изменения в программу и её документацию. Начав работу над кандидатом на выпуск, следует вести очень строгий контроль любых изменений. Не обманывайте себя, думая, что всё готово, когда на самом деле все наоборот. Чтобы внести ясность в этот вопрос, пройдёмся по основным требованиям, предъявляемым к кандидатам.
•
Все без исключения функции должны быть завершены на 100%. Участники команды должны быть уверены, что цель разработки ПО достигнута и в случае успешного завершения тестирования в ПО больше не планируется вносить никаких изменений.
•
Команда полностью завершила работу над справочной системой программы, электронной документацией, информационными файлами и электронными учебниками. Материалы проанализированы, выверены и полностью закончены. Можно дать ещё неделю на завершение подготовки печатной документации, но электронная документация, которая будет поставляться с ПО, должна быть готова.
•
Группа уже закончила оценку и доводку пользовательского интерфейса, так что интерфейс останется неизменным вплоть до отправки продукта заказчику;
•
Группа выполнила план тестирования в полном объёме: проведено блочное, системное, нагрузочное тестирование, тестирование производительности и испытание пользовательского интерфейса, а также автоматизированное тестирование. Все тесты пройдены, по крайней мере, известны все неполадки и решено поставлять продукт, не устраняя их.
•
Все ошибки, которые планировалось исправить, уже исправлены. Что касается остальных ошибок, то, проанализировав все сообщения о неисправленных ошибках, группа пришла к выводу, что они не могут или не должны быть исправлены в этом выпуске ПО.
Тестирование кандидата на выпуск
Фактически кандидат на выпуск и есть та версия ПО, которая будет отправлена заказчику, если последний цикл тёстирования не выявит серьёзных проблем. Даже если время ограничено, всё равно нужно протестировать ключевые функции ПО на его окончательной сборке, а это значит, что тестирование придётся вести очень напористо. Рассмотрим основные процедуры тестирования кандидатов на выпуск.
Обеспечив соответствие программы начальным требованиям к кандидатам на выпуск, можно приступать к созданию окончательной сборки ПО. На этом этапе необходимо:
• остановить все изменения в системе управления версиями и заблокировать систему управления исходным текстом;
• создать одну полную сборку программы на основе окончательной версии исходного текста (с использованием оптимизации при компиляции);
• прекратить создание новых сборок — с этого дня ежедневная сборка ПО отменяется;
• пометить нужные файлы в системе управления исходным текстом;
• уведомить всех участников команды о том, что кандидат на выпуск готов!
