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