Глава 12: Планирование и документация 301

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

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

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

• Канер (Капег) и Фолк (Folk) полагают, что для тестирования при­кладного программного обеспечения эволюционный подход всегда лучше.

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

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

302 Часть II: Приемы и технологии тестирования

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

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

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

• Не во власти тестировщика или даже руководителя группы тестиро­вания изменить философию компании.

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

Следует упомянуть о двух главных преимуществах эволюционной раз­работки тестового плана.

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

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