368 Часть III: Управление проектами и группами

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

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

Модель разработки и тестирование

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

• Как можно раньше проанализируйте пользовательский интерфейс.

Можно воспользоваться для этого прототипами программы.

• Как можно раньше начните разработку тестового плана. Это по­зволит критически проанализировать спецификацию (или ее черно­вики) и выявить возможные проблемы, связанные с тестированием будущего продукта.

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

Глава 13: Объединяющая 369

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

• Тестирование — это наиболее ответственный этап разработки.

К моменту начала тестирования программа уже практически полно­стью написана. После прекращения поиска ошибок она сразу же выходит в свет. Если проект достаточно велик для подключения нескольких тестировщиков, подумайте о том, чтобы назначить одно- го-двух человек для постоянного выполнения неформального тести­рования. Цель работы такого сотрудника — каждую неделю находить пару настолько серьезных ошибок или недостатков, что выпустить с ними продукт просто невозможно. Во время исправления этих оши­бок остальная часть группы будет последовательно “прочесывать” программу в соответствии с планом. Эта тактика особенно хорошо зарекомендовала себя на больших и серьезных проектах, где она позволяет сэкономить очень много времени. (Предупреждение: ни­когда не откладывайте документирование серьезных ошибок, прибе­регая их на случай, если за неделю не удастся выявить ничего серьезного. Такие вещи могут очень дорого вам обойтись, особенно если кто-нибудь об этом узнает. Никогда этого не делайте. Никог­да об этом даже не думайте.)

А вот каковы следствия выбора эволюционного метода.

• Планируйте рано начать тестирование. Как только будет сформи­рован базовый набор функций программы, необходимо будет при­ступить к тестированию ее надежности.

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

• Планируйте разработку тестового плана параллельно с тестирова­нием. Заранее разработать его не удастся — ведь не будет ни пред­мета тестирования, ни даже спецификации.

Идея

Анонсирование продут

Формирование основной команды

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

Написание тестового плана

Написание спецификации

Выпуск продукта

III

Кодирование	■■■■■
	■■■■■ ■■■
Проектирование
	■■■ ■■
Прием заказов
	■■
Тестирование

■

■

■

■

■

Хотя теоретическая модель и важна, не менее важна эффективность ее реализации. Читая о последовательно к этому рисунку.

РИСУНОК 13.1. Цикл разработки продукта