Тестирование кандидата на выпуск

Тестирование кандидата на выпуск

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

Создание окончательной сборки

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

• остановить все изменения в системе управления версиями и заблокировать систему управления исходным текстом;

• создать одну полную сборку программы на основе окончательной версии исходного текста (с использованием оптимизации при компиляции);

• прекратить создание новых сборок — с этого дня ежедневная сборка ПО отменяется;

• пометить нужные файлы в системе управления исходным текстом;

• уведомить всех участников команды о том, что кандидат на выпуск готов!

Автоматизированное и ручное тестирование

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

• проверке установки и функций, связанных с лицензированием;

• тестировании базовой функциональности продукта, а именно:

— ключевых функций;

— основных элементов пользовательского интерфейса;

— важнейших ссылок в справочной системе;

— программ-примеров и электронных учебников;

• самых необходимых тестах производительности и нагрузочном тестировании;

• других специфичных для данного проекта функциях, которые требуется протестировать.

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

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

Из собственного опыта

Для работы над кандидатами на выпуск в NuMega обычно приглашают только лучших бета-тестеров. По завершении внутренних тестов мы посылаем программу тестерам кандидатов на выпуск с просьбой вынести в течение 3-5 дней вердикт: готово ПО или нет. Администратор бета-тестирования остаётся на связи с тестерами: если возникают проблемы, тестеры получают приоритетную поддержку, часто прямо от разработчиков. Когда сильно поджимают сроки, отзывы клиентов могут быть как весьма обнадёживающими, так и очень тревожными. После начала поставок продукта мы часто дарим нашим тестерам его копию вместе с футболками разработчиков в благодарность за их труд.

Обеспечьте «мягкую посадку» проекта

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

Поскольку работа над кандидатом на выпуск — критический период проекта, он требует открытого обмена точной информацией о состоянии проекта, отражающей как успехи, так и неудачи. В этот период необходимо оперативно принимать решения, чтобы устранять ключевые затруднения, исправлять ошибки, контролировать риск и выбирать между альтернативами. Чтобы справиться с этими задачами, нужно создать «штурмовую группу», состоящую из лидеров всех функциональных подразделений:

• разработчиков;

• тестировщиков;

• группы по обучению пользователей;

• группы инженерной психологии;

• технологов;

• технической поддержки;

• менеджера продукта;

• администратора бета-тестирования.

Из собственного опыта

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

Идея состоит в создании штабного помещения — единственного места, где можно ставить, анализировать и обсуждать проблемы. Антикризисные собрания должны проводится ежедневно в одной и той же комнате. Такой подход, использующий предварительное планирование, позволяет формализовать и упорядочить область ответственности каждого специалиста, докладывающего о состоянии дел в ней, а также о накопившихся проблемах. По мере проведения заключительных тестов и поступления клиентских отзывов извне, накапливается значительная информация, которую можно и нужно довести до сведения каждого члена группы. Даже когда проблемы и трудности отсутствуют, всё равно неплохо собраться всем вместе, чтобы разделить эту хорошую новость. Наконец, если требуется немедленно принять критически важное решение, можно просто созвать экстренное собрание «штурмовой группы».

Если что-то идёт не так, стоит задуматься

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

• Прояснить проблему

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

• Оценить затраты на исправление ошибок или внесение изменений

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

• Решить, делать ли новую сборку программы

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

Если решено создать новую сборку, следует назвать её с учётом схемы именования RCn+1, где n — номер версии последнего кандидата на выпуск. Проследите, чтобы номер сборки нового кандидата стал известен каждому.

• Выполнить повторный цикл тестирования кандидата на выпуск

Если неполадка локальна, достаточно повторного тестирования лишь той части программы, что была изменена при её устранении. Однако повторное тестирование программы установки следует провести в любом случае.

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

Если всё в порядке, можно заканчивать

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

• Технические специалисты

Все подразделения: разработчики, тестировщики, специалисты по обучению пользователей, инженерные психологи и технологи — должны единогласно утвердить проект. Это означает, что каждое подразделение внесло свой вклад в создание реального продукта и готово дать ему «зелёный свет». В рамках модели, принятой в NuMega, за готовность проекта в конечном счёте отвечает менеджер проекта, а сама готовность определяется по согласованию с командой. Технические специалисты первыми ставят свою подпись под проектом, без их визы проект дальше не пойдёт.

• Менеджеры продукта

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

• Группа технической поддержки

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

• Заказчики

Виза заказчиков означает, что продукт готов к использованию в их производственном или коммерческом окружении.

Когда продукт готов, можно передать его заказчику

После того, как все дали «зелёный свет» можно передавать проект заказчику и принимать поздравления с окончанием работы! Но прежде, чем считать проект завершённым, обязательно прочитайте следующую главу, «Закрытие проекта» (вот тогда проект действительно будет закрыт).