Тестирование-книга. Ю. Н. Артеменко Научный редактор
 Скачать 6.27 Mb.
|
|
Непредвиденные обстоятельства. Что делать, если что-то пойдет не так. Перечень необходимых элементов Этот документ сопровождает материалы, необходимые для проведения тестов. В нем сказано, что именно получает тестировщик. В соответствии со стандартом 829 он включает следующие разделы. • Идентификатор перечня необходимых элементов. • Передаваемые элементы. В этом разделе указываются имена и но мера версий предоставляемых программ и модулей, а также фами лии людей, ответственных за их предоставление. • Местонахождение. Где будут находиться предоставленные матери алы — на диске, ленте, в общем каталоге, в папке? Как они поме чены? • Состояние. Изменились ли тестируемые компоненты с тех пор, как вы в последний раз с ними работали? Какие из документированных проблем уже решены? Изменилась ли спецификация или поведение программы? Какие из изменений могли отразиться на надежности программы? Отличаются ли предоставляемые материалы от специ- Глава 12: Планирование и документация 3 5 3 фикации или руководства и, если да, какие из документов правиль ны? Какие еще предстоят значительные изменения? • Утверждение. Сотрудники, ответственные за предоставляемые ма териалы, должны подписать данный документ, подтверждая, что все элементы готовы к тестированию. Тестовый сценарий Этого документа в стандарте 829 нет. О его назначении и содержании уже рассказывалось в разделе "Сценарий теста для неопытного тестиров- щика". Вот из чего он состоит. • Инструкции общего характера. Это пояснения о том, как читать и использовать сценарий, как и когда заполнять отчеты о проблемах, где их найти и т.п. Всю эту информацию можно предоставить тес- тировщику в виде отдельного документа, чтобы не перегружать сце нарий, однако в любом случае неопытному тестировщику она абсолютно необходима. • Начало. В этом разделе приводится описание процесса настройки среды и подготовки к выполнению теста. • Пошаговые инструкции для выполнения каждого теста. • Квадратики для отметок о прохождении каждого шага и отметок о результатах. • ПОЛЯ для описания поведения программы, а также для заметок обо всем непонятном и вопросы, ответами на которые должны служить эти описания. Позднее опытный тестировщик проанализирует эти ответы, самостоятельно проанализирует нестандартное поведение программы и, вероятно, напишет целый ряд новых отчетов о про блемах. Журнал тестирования Этот журнал предназначен для протоколирования процесса тестирова ния и всех заслуживающих внимания событий. Стандарт 829 определяет, что он должен состоять из следующих разделов. • Идентификатор журнала тестирования. • Описание. Тестируемый объект, включая номер версии, место про ведения тестирования, аппаратное обеспечение (тип компьютера, объем памяти, принтер и т.п.), информация о программной конфи гурации (операционная система, номер ее версии и т.п.). • Действия и события. Что происходило в процессе тестирования. Запись может включать следующие составляющие. 3 5 4 Часть II: Приемы и технологии тестирования • Процесс. Какой была процедура тестирования, кто был свидете лем происходящего и какой была роль этого человека в выполне нии теста. • Результаты. Что произошло, что вы видели, слышали и т.п., где записаны выходные данные. • Аномальные события. Неожиданные события (как правило, объясняющиеся ошибками в программе). Что происходило до и после них. • Идентификаторы отчетов об инцидентах. Номера составленных отчетов о проблемах. Отчет об инциденте во время тестирования Это отчет о проблеме. Форма отчета, описанная в данной книге, отли чается от стандарта IEEE. По стандарту в отчете должны быть следующие поля: идентификатор отчета, описание, входные данные, ожидаемые ре зультаты, реальные результаты, аномалии, дата и время, шаг процедуры, среда выполнения, попытки повторения теста, тестировщики, наблюдате ли, ссылки на тестовые планы и спецификации. Итоговый отчет В конце каждой серии тестов составляется итоговый отчет, и такой же отчет составляется по завершении цикла тестирования. В нем коротко описывается проделанная работа и оцениваются ее результаты. Вот какие разделы определяются для этого отчета стандартом 829. • Идентификатор итогового отчета. • Описание. Что тестировалось (включая номера версий), в какой среде, как вы оцениваете полученные результаты? Приведите ссылки на спецификации тестов. • Отклонения. В чем и почему процедура тестирования отличалась от описанной в спецификации? • Оценка адекватности тестирования. Было ли тестирование на столько полным, как того требует тестовый план? Какие модули, функции, возможности программы или их комбинации протестиро ваны недостаточно и почему? • Обобщенное описание результатов. Какие выявлены проблемы, какие из них устранены, каковы принятые решения? Какие из про блем оставлены нерешенными? • Оценка. Общая оценка каждого из элементов (программ, модулей) на основе результатов его тестирования. Каков риск, связанный с его реальной эксплуатацией, и вероятность сбоев (необязательно)? Глава 12: Планирование и документация 3 5 5 • Затраченные ресурсы. Сколько людей работало над описанными тестами, сколько затрачено машинного времени, рабочего времени сотрудников, какие еще использованы ресурсы и какие произошли нестандартные события. • Утверждение. Документация в файлах данных и управляющих файлах Создавая файлы входных данных для тестов, старайтесь по возможно сти включать в них комментарии, поясняющие выбор каждого из значений. То же самое касается и файлов, управляющих выполнением тестов. Если их форматом допускаются комментарии, не скупитесь на пояснения к каждому выполняемому этапу. Лучше всего организовать тестирование таким образом, чтобы, выпол няя каждый из тестов, видеть на экране или на бумаге его ожидаемые результаты. Тогда их сразу же можно сравнивать с полученными. В этом случае отображать или распечатывать описания причин выбора того или иного значения данных или той или иной процедуры не следует. Эта ин формация будет только занимать лишнее место и отвлекать тестировщика от результатов теста. Гораздо лучше, если она просто будет всегда под рукой (например, в файле, который можно открыть в любой момент). В отношении встроенных комментариев существует одна сложность — по сравнению с документацией они гораздо менее стандартизированы. Фактически их форма отдается на откуп автору, и есть вероятность, что некоторые файлы останутся вообще недокументированными или коммен тарии в них будут поверхностными и неаккуратными. И уж во всяком случае комментарии редко бывают такими подробными, как распечатанные документы. Однако есть у комментариев и важное преимущество — их легко обнов лять. Когда сотрудник изменяет процедуру тестирования, комментарий находится прямо у него перед глазами. К тому же комментарии не теряют ся — если у вас есть тестовый файл, значит, есть и текст его описания. Заключение Многие тестировщики слишком увлекаются написанием бумаг, забывая, что их основная работа — поиск и исправление ошибок. В этой главе описан целый ряд документов, но это вовсе не означает, что необходимо составлять их все. Отбирайте только самое необходимое, сообразуясь с нуждами конкретного проекта. III Часть Управление проектами и группами Глава 13. Объединяющая Глава 14. Управление группой тестирования Приложение. Распространенные программные ошибки Глава Объединяющая Назначение этой главы Итак, вы у ж е знаете, как тестировать программное обеспечение, как пла нировать эту работу, и имеете представление о том, как плановые и про ектные документы связаны с ее результатами. Теперь пришло время перейти от технических вопросов к организационно-стратегическим. Реальный мир полон ограничений. Не только желательную работу никогда не удается выполнить в полном объеме, но д а ж е ту, которую, на ваш взгляд, вы обязаны сделать. (Таким был урок второй главы.) Не лучше положение и у руководителя проекта. Он пытается соблюсти разумный компромисс м е ж д у надежностью продукта, его функциональными возможностями, сто имостью и скоростью разработки. Поэтому, делая упор на качество продук та, он должен идти на уступки в других не м е н е е важных для компании вопросах. В разговорах с руководителем следует обязательно это учитывать и не упорствовать в том, что кажется полезным с точки зрения полноты те стирования — старайтесь, как и он, сохранять широту взгляда на вещи и рас сматривать все проблемы с точки зрения пользы для проекта в целом, а не только своего узкого участка работы. Тогда у вас всегда будет взаимопо нимание. С точки зрения реального проекта в реальном мире работа группы тести рования всегда связана с затратами. Они должны окупаться, а окупиться они могут не иначе, как если будут удовлетворены запросы пользователей и повысятся доходы компании. Именно это и является главным критерием оценки результатов вашей работы, и именно это позволит получить допол нительное финансирование — только докажите, что оно окупится. И лучший способ доказать окупаемость своей работы — это показать, что она позво ляет снизить другие затраты, связанные с качеством продукта. В самом начале каждого проекта его руководитель вырабатывает стратегию, позволяющую максимально снизить затраты на разработку и обладающую той степенью гибкости и той направленностью, которые помогут наиболее эффективно решить поставленные задачи. Выбранная руководителем стратегия разработки м о ж е т оказаться классическим методом водопада, эволюционной 13 Глава 13: Объединяющая 3 5 9 схемой или же его собственной вариацией одного их этих двух методов. М е н е е вдумчивый м е н е д ж е р м о ж е т просто следовать однажды усвоенному подходу, не задумываясь об иных возможностях и их преимуществах. Как бы там ни было, выбранная им модель определяет, когда и в каком порядке выполняются различные виды работ, и в частности, когда продукт тестиру ется и когда в него вносятся исправления. Вам как руководителю группы те стирования необходимо понимать выбранную модель до мельчайших деталей. Иначе, планируя работу своей группы, вы рискуете наделать серьезных оши бок. Например, если значительная часть тестирования пользовательского ин терфейса программы будет проведена на этапе, когда изменить его будет у ж е нельзя, большинство документируемых вами проблем так и останутся нерешенными. Если же некоторые изменения все же будут внесены в про грамму, это м о ж е т нарушить планы других сотрудников, работающих над проектом. Так что плохо будет всем. Итак, для эффективной работы и гладких взаимоотношений с руководством исключительно важно правильно понимать цели, преследуемые руководите лем проекта при планировании распределения затрат и направлений основ ных усилий, выбранную им стратегию разработки, а т а к ж е видеть полное соотношение составляющих качества продукта и связанных с ними затрат к о м пании. Только тогда вы с м о ж е т е говорить с руководителем проекта на его языке и только тогда с м о ж е т е объяснить, а если необходимо, и доказать, что для полноценного тестирования продукта, отвечающего задачам данно го проекта, необходимо выполнить такие-то виды работ в таком-то объеме, а если этого не сделать, то возможны такие-то и такие-то последствия. В данной главе речь пойдет о разбиении проекта на ряд последовательных этапов. Рассказывая о т о м , какая работа выполняется на к а ж д о м из этих этапов, мы основывались на опыте, полученном нами (и нашими коллегами) в ходе множества проектов во множестве компаний. Однако приведенные рекомендации НЕ следует рассматривать как Единственно Правильный Спо соб организации проекта. Напротив, как и с любым другим способом, с ним связано множество проблем. Однако, скорее всего, структура вашего про екта будет очень похожа на описанную в этой главе. Мы же хотим просто помочь вам в выборе необходимых типов тестирования. Обзор В данной главе рассматриваются следующие вопросы: • Чем приходится поступаться при разработке программного обеспечения • Модели разработки • Затраты, связанные с качеством продукта • Сроки разработки • Проект продукта • Анализ пользовательских данных • Первоначальная функциональность • Почти альфа • Альфа 3 6 0 Часть III: Управление проектами и группами • Пре-бета • Бета • Бета-тестирование вне компании • Замораживание пользовательского интерфейса • Перед завершением • Коэффициенты надежности • Последняя проверка целостности • Выпуск продукта • Анализ продукта после его выпуска Библиография По вопросу о контроле качества программных продуктов можно порекомен довать бестселлер Американского общества контроля качества (American Society for Quality Control) Principles of Quality Costs (Campanella, 1990). Он будет очень полезен тем, кто захочет внедрить в своей компании систему контроля затрат на качество продукта. Кроме того, интересны книги таких авторов, как Джуран и Грайне (Juran & Gryna, 1980), а также Фейгенбаум (Feigenbaum, 1991). В главе 3 уже рассказывалось о стадиях разработки, и многие определен ные там концепции используются в данной главе. Гласе (Glass, 1992) рассмат ривает этапы р а з р а б о т к и п р о г р а м м н о г о продукта с точки зрения руководителя проекта, помогающего программистам улучшить его качество. Чем приходится поступаться разработчикам программного обеспечения Работа руководителя проекта заключается в том, чтобы обеспечить выпуск высококачественного продукта в заданные сроки и при этом уло житься в рамки отпущенного бюджета. Однако эта задача не всегда оказы вается выполнимой. В сфере разработки программного обеспечения превышение сроков и бюджета — самое обычное дело. Чтобы все же выполнить свою задачу и удержать проект в рамках от пущенного времени и ресурсов, его руководителю в определенные моменты приходится пересматривать имеющиеся результаты работы и решать, какие из оставшихся задач должны быть обязательно выполнены, а от каких при дется отказаться за неимением времени или денег. Такой пересмотр даль нейших планов может выполняться за несколько месяцев или дней до выпуска продукта. А поступаться в конечном счете приходится следующим: • надежностью продукта; • количеством и глубиной его функций; Глава 13: Объединяющая 3 6 1 • деньгами, необходимыми для выполнения дальнейшей работы; • сроками выпуска продукта. В принятии решения, особенно на поздних стадиях разработки, огром ную роль играет гибкость выбранной стратегии. Но какой бы ни была эта стратегия, возможности руководителя проекта ускорить и удешевить его разработку будут ограничены рядом естественных факторов. • Надежность. Чтобы удешевить продукт и выпустить его быстрее, проще всего сократить время тестирования и оставить в программе множество ошибок. Однако, даже если этого не делать, в продукте все равно останется некоторое количество ошибок, которые могли бы быть выявлены в ходе дальнейшего тестирования. Ведь тестирование — процесс бесконечный, но так или иначе когда-нибудь приходит ся остановиться. • Функциональность. Еще один способ сокращения проекта заключа ется в его упрощении. Если одна из функций продукта плохо спро ектирована или закодирована или же техническая сложность ее реализации оказалась недооцененной, руководитель проекта может сэкономить время и деньги, просто отказавшись от этой функции, или оставив ее усеченный вариант. Однако не с каждой функцией программы можно поступить подобным образом. Отсутствие неко торых составляющих может резко снизить ценность продукта для пользователя. То же самое касается и неудобных способов решения определенных задач. • Деньги. Бывает, что для успешного завершения проекта необходимо пойти на дополнительные затраты. Возникшие проблемы можно решить таким образом: купить дополнительный инструментарий, нанять высокопрофессиональных консультантов или подключить дополнительный персонал. Последний вариант используется чаще всего, однако это не всегда помогает. Ведь чем больше людей рабо тает над проектом, тем больше возникает всевозможных проблем и тем выше его стоимость. Руководящие сотрудники вынуждены от влекаться от своих основных задач, организуя работу нового персо нала. В результате это может даже затянуть весь процесс разработки. (См. Брукс (Brooks, 1995).) Это касается дополнительного подклю чения к работе как программистов, так и тестировщиков. В конце проекта и тот, и другой варианты могут серьезно дестабилизировать работу всей команды. • Дата выпуска. Если проект выбивается из графика, его руководи тель может отложить выпуск. Однако это может обойтись компании крайне дорого. 3 6 2 Часть III: Управление проектами и группами • Непосредственная стоимость продолжения работ. Эти затраты определяются зарплатой всех участников проекта. • Дополнительные потери. Если работа выполняется по контракту, руководитель может предусмотреть пеню за несоблюдение сроков или значительный бонус за своевременное завершение проекта. Если продукт должен быть выпущен к началу определенного се зона, например, к осени, Рождеству или Новому году, пропустив его, можно потерять часть покупателей. Кроме того, задержка выпуска продукта может привести к тому, что устареет техника, на которую он ориентирован, или на рынке появятся конкуриру ющие продукты. Очень важно понимать, что рынок завоевывает продукт, появившийся первым, и по количеству продаж он пре взойдет более качественные продукты, выпущенные какое-то время спустя. Поэтому задержка выпуска ради повышения каче ства продукта может его похоронить. • Потерянные затраты на маркетинг. Если продукт разрекламиро ван слишком рано, к моменту его выпуска придется все повторять сначала. • Параллельные проекты. Люди, работающие над проектом сверх срока, могли бы уже выполнять другую работу. Таким образом, задержки одного проекта отражаются и на других. • Отсутствие ожидаемой прибыли. Если доходы от выпуска продук та должны быть немедленно вложены во что-то другое, если эти деньги срочно нужны компании — тогда у вас большие пробле мы. Модели разработки программного обеспечения Модель разработки программного обеспечения — это тот принцип, по которому руководитель проекта составляет план выполнения задач. О клас сических моделях разработки, их достоинствах и недостатках подробно рассказывалось в главе 12. Пример организации работ по методу водопада приводился в главе 3. Этот же метод мы еще раз рассмотрим с другой точки зрения в главе 14. У каждой модели свое соотношение возможностей ускорения и удешев ления проекта. Поэтому руководитель должен решить, какие его составля ющие с наибольшей вероятностью могут подвергнуться изменениям, и выбрать модель, наиболее гибкую именно в этих областях. Если, например, набор функций программы жестко фиксирован и ни одна из них ни в коем случае не может быть удалена, бессмысленно выбирать модель, ориентиро ванную на снижение стоимости продукта за счет сокращения его функций. Глава 13: Объединяющая 3 6 3 Обычно у любого специалиста в этой области имеется четкое представ ление об относительных преимуществах и недостатках каждой модели. Однако, несмотря на профессиональный опыт и веские логические обосно вания, эти представления весьма субъективны. В частности, собственное мнение на этот счет имеется и у каждого из авторов этой книги, однако эти мнения различны. Имея это в виду, никогда не пытайтесь критиковать руководителя проекта за Неверный Выбор Модели разработки. В следующих двух разделах рассказывается о проблемах и путях их решения, связанных с методом водопада и эволюционной моделью разра ботки. На их примере мы хотим показать, как следует подходить к анали зу любой модели, которая покажется заслуживающей внимания. Попробуйте подобным образом проанализировать методики, используемые в вашей компании. Традиционный метод водопада Метод водопада представляет собой классический подход к управлению проектом. Особенно часто он применяется для крупных разработок. В соответствии с этим методом проект разбивается на ряд последовательных этапов — анализ требований, разработка проектной документации, коди рование, тестирование и выпуск. Подавляющая часть работ каждого этапа завершается до начала следующего. Например, разрабатываются функцио нальные требования к продукту. Когда этот документ готов, начинается разработка внутренней и внешней спецификации. После завершения и утверждения спецификаций начинается кодирование. В теории все звучит красиво и очень убедительно. Таков стандартный подход, и руководители многих групп тестирования просят программистов его придерживаться. Тестировщики задолго до начала тестирования полу чают в руки спецификацию, полностью описывающую продукт и ограни чивающую количество его последующих изменений. Спецификация облегчает планирование работ по тестированию, формирование их бюдже та, календарного плана, подбор персонала. Описываемый метод первоначально предназначался для разработки программного обеспечения по контрактам. В этом случае требования к продукту формирует заказчик, и делается это заранее, поскольку на их основе определяется стоимость разработки. Кроме того, заказчик должен проанализировать и одобрить внешний дизайн, спецификации многих потоков данных, определения многих отчетов и еще целый ряд других деталей, причем все эти документы должны быть согласованы до начала кодирования. Только после этого начинается собственно создание продукта. Если требования заказчика к продукту по каким-либо причинам изменят ся, эти изменения вносятся в продукт, но вся уже проделанная работа все равно оплачивается. Именно такова юридическая схема действий, но кто сказал, что юристы — хорошие инженеры? 3 6 4 Часть III: Управление проектами и группами Серьезнейшим недостатком метода водопада является то, что все клю чевые конструкторские решения должны быть приняты на этапе, когда сотрудники еще не составили полного представления о продукте. В значи тельной степени оно формируется в ходе разработки, а до ее начала легко ошибиться в оценках сложности или наилучшего способа реализации от дельных функций. Еще мало изучены конкурирующие программы. Еще не сформировано четкое представление о разрабатываемом продукте — реаль ном, а не планируемом, поскольку, только поработав с программой доста точно долгое время, можно как следует оценить ее сильные и слабые стороны, почувствовать ее характер. Все это станет возможно только пос ле создания первой работающей версии продукта. Каковы же возможности руководителя проекта, который близок к за вершению, но не укладывается в сроки, если проект разрабатывается по методу водопада? • Функциональность. К этому моменту все требования к продукту уже давно сформированы, спецификация готова, и если продукт нахо дится на тестировании, то и кодирование также завершено. Поэто му удаление функций в общем случае незначительно сокращает время или стоимость разработки. Если одна из функций спроектирована или реализована настолько плохо, что всю работу необходимо переделать, тогда ее удаление из продукта может пойти на пользу проекту. Однако, если от неудач ной функции зависят другие части продукта, сделать это уже не так просто. • Деньги. Поскольку спецификация полностью готова, ничего не стоит подключить к проекту дополнительных программистов. Получив четкое и ясное представление о поставленной задаче, они могут сходу приступать к кодированию. • Дата выпуска. Когда проделано столько подготовительной работы, жалко от чего-либо отказываться. Поэтому, часто, когда все функ ции программы уже закодированы, принимается решение продлить сроки разработки и провести все запланированное тестирование. • Надежность. Если все функции уже написаны, подключен допол нительный персонал, а проект по-прежнему не укладывается в сро ки, остается только прекратить тестирование и выпустить продукт как есть, со всеми оставшимися в нем ошибками. В этом случае давление на тестировщиков невероятно возрастает, у них остаются считанные дни на то, чтобы либо доказать, что продукт не готов к выпуску, либо подтвердить, что в нем нет слишком серьезных оши бок. Последнее, впрочем, лишь предположение, базирующееся на том факте, что подобных ошибок не выявлено в течение последних дней. Глава 13: Объединяющая 3 6 5 Итак, если проект разрабатывается по методу водопада и не укладыва ется в график, его руководитель может подключить дополнительный пер сонал, отложить дату выпуска или выпустить некачественный продукт. Защитники этого метода утверждают, что многих неприятностей мож но избежать, если программисты с самого начала проанализируют требо вания и проектную документацию и тщательно спланируют свою работу. Если же какую-либо из задач не продумать заранее, ее решение в дальней шем будет связано с большими проблемами. Тщательность предваритель ного планирования особенно важна в тех случаях, когда продукт разрабатывается для одного пользователя или когда значительную часть продукта составляет аппаратное обеспечение, которое невероятно дорого перепроектировать. Эволюционный метод При эволюционном подходе к разработке программного продукта фун кции добавляются к нему последовательно, одна за другой. Любая программа может обладать минимумальным количеством функ ций, а может быть напичкана всем, что только пришло в голову програм мисту. При эволюционном подходе продукт развивается в направлении от первой крайности ко второй. Это значит, что вначале продумывается суть будущей программы, ее идеология и основные задачи. Затем программис ты пишут ядро программы, спроектированное таким образом, чтобы ее легко можно было расширять, добавляя все новые и новые возможности. Набор функций ядра минимален, однако они все же составляют независи мую программу, готовую к тестированию. Ядро тестируется и отлаживает ся как полноценный продукт до тех пор, пока не получится вполне стабильная программа. Затем программисты добавляют к продукту новые функции — по одной или небольшими связанными группами. После каждого такого добавления программа проходит новый цикл тестирования и исправляется до тех пор, пока снова не станет достаточно стабильной. Процесс добавления функций и отладки программы продолжается до тех пор, пока не получится достаточно приемлемый продукт. Это означа ет, что, если необходимо, его уже можно продавать, хотя и остается еще множество нереализованных функций, которые могли бы сделать его бо лее конкурентоспособным. Но и без них продукт представляет собой по лезную программу, которая вполне удовлетворит многих потенциальных пользователей. Дальше все зависит от наличия времени и денег. Если разработку про дукта можно продолжить, его возможности постепенно расширяются все тем же эволюционным методом: добавили функцию — отладили програм му, добавили следующую — опять отладили. Благодаря такой стратегии 3 6 6 Часть III: Управление проектами и группами компания постоянно имеет полноценную и стабильную программу, даль нейшее усовершенствование которой можно прекратить в любой момент, зная, что вся наиболее важная работа уже выполнена. Со временем про грамма вырастает в надежный и полезный продукт с богатыми возможно стями. При методе водопада группа тестирования находится в состоянии по стоянной неопределенности. Как составить реальный календарный план работ, когда никому не известно, сколько еще в программе ошибок и сколько времени понадобится на их поиск и устранение? При эволюцион ном подходе все гораздо определеннее. Как минимум последняя отлажен ная версия продукта всегда готова к выпуску, а в новой версии добавлена только одна функция, так что область поиска ошибок достаточно локали зована. Последним преимуществом эволюционного подхода является его гиб кость: по ходу работы и по мере углубления понимания продукта требова ния к нему можно пересматривать, а это значит, что в конечном счете продукт получается более совершенным. Вот что можно сделать, если проект, реализуемый эволюционным ме тодом, выбивается из графика. • Функциональность. Как только сформирован минимальный набор функций, образующих приемлемый продукт, от остального можно спокойно отказаться. Раз программисты не проектируют новых функций до тех пор, пока не наступает время их добавления, такой отказ не будет означать, что значительный объем работы по проек тированию и написанию документации проделан зря. • Деньги. Вместо того чтобы отказаться от добавления новых функ ций, можно реализовать их быстрее, подключив дополнительные ресурсы. Узким местом в этом случае станет проектирование про дукта, поскольку подключить новых конструкторов гораздо сложнее, чем исполнителей. • Дата выпуска. Главная мощь эволюционного подхода заключается в том, что он предоставляет руководству невероятные возможности контроля за графиком работ. Дата завершения проекта свободно может переноситься в ту или иную сторону в зависимости от требо ваний момента. И нередко руководитель решает выпустить продукт вовремя, не добавляя в него оставшийся десяток функций. При этом, когда бы ни было принято решение о выпуске, сделать это можно буквально в течение нескольких недель, ведь продукт всегда стабилен. • Надежность. Продукты, разрабатываемые эволюционным путем, всегда очень надежны. Поскольку после добавления каждой новой Глава 13: Объединяющая 3 6 7 функции продукт полностью отлаживается, основные усилия по тестированию приходятся на начало проекта. Когда руководство решает прекратить разработку и выпустить программу в свет, необ ходим лишь незначительный объем завершающего тестирования, чтобы подтвердить ее готовность. При этом, даже если такое реше ние принимается раньше срока или до того, как все задуманное будет полностью реализовано, нет риска, что выпущенная программа будет содержать серьезные ошибки. Затраты на тестирование продукта при эволюционном подходе довольно велики, поскольку оно начинается очень рано. Однако ближе к концу разработки объем тестирования гораздо меньше, чем при методе водопада, что несколько уравнивает расходы. К тому же не приходится тратить вре мя на планирование тестов и тестирование тех функций, от реализации которых руководство откажется в случае цейтнота. Однако в реализации эволюционного метода разработки существуют и сложности. Одна из них заключается в том, что программистам приходится совмещать написание нового кода с отладкой старого. Если разработка не укладывается в сроки, у них возникает искушение вместо исправления ошибок быстро программировать новые функции. Однако делать этого ни в коем случае нельзя, поскольку прогресс получается только кажущимся. Ошибки будут накапливаться, и это сведет на нет все преимущества выб ранной стратегии. В результате руководителю проекта придется делать выбор между выпуском некачественного продукта и переносом даты завер шения проекта. При выборе эволюционного подхода неопытным руководителем суще ствует определенный риск. Руководителю может показаться, что, поскольку продукт развивается со временем, нет нужды проводить тщательное началь ное планирование. Это огромная ошибка. Успех всей разработки зависит от гибкости ядра и продуманности основных концепций. А для достижения гибкости необходимо даже более тщательное планирование, чем при методе водопада, ведь должны быть предусмотрены все возможные способы и направления расширения продукта. Если же ядро разработано неудачно, при добавлении каждой новой функции программы его придется переде лывать, а это сведет на нет все преимущества выбранного подхода. Кроме того, в конце разработки может оказаться, что не хватает одной из важней ших функций, без которых продукт не будет полноценным, и придется добавлять ее, отодвигая дату выпуска. Не всегда правильно понимают суть эволюционного метода сотрудни ки группы маркетинга. Рекламируя продукт, они нередко анонсируют те его функции, которых в конечном варианте может не оказаться. Нет нужды говорить, что такого быть ни в коем случае не должно. 3 6 8 Часть III: Управление проектами и группами У руководства есть и еще один способ завалить проект, разрабатывае мый эволюционным методом. Если не начать тестирование продукта сра зу же, как только будет готово его ядро (а такое может случиться, если все тестировщики заняты на другом проекте, выбивающемся из графика), бу дет нарушена вся стратегия. К тому времени, когда к ядру начнут подклю чаться новые функции, оно еще не будет полностью отлажено. С ростом сложности продукта тестировщикам и программистам крайне сложно будет наверстать упущенное и привести очередную версию к состоянию полной стабильности. В результате получится нечто похожее на плохо организован ный проект, разрабатываемый по методу водопада: тестирование начато достаточно поздно, продукт очень нестабилен, и к тому же спецификация все время пересматривается, к программе добавляются все новые и новые функции, когда и старые еще работают кое-как. Приходится подключать к тестированию дополнительные ресурсы, его стоимость непомерно возрас тает, а проект все равно выбивается из графика, и качество результата оставляет желать лучшего. При любом подходе к разработке от группы тестирования зависит очень многое. Но при эволюционном методе у нее больше всего возможностей завалить работу, и этот риск обязательно следует учитывать. Модель разработки и тестирование Как следует разобравшись в выбранной руководителем проекта модели разработки, следует проанализировать ее влияние на процесс тестирования. Вот что означает для тестировщиков выбор метода водопада. • Как можно раньше проанализируйте пользовательский интерфейс. Можно воспользоваться для этого прототипами программы. • Как можно раньше начните разработку тестового плана. Это по зволит критически проанализировать спецификацию (или ее черно вики) и выявить возможные проблемы, связанные с тестированием будущего продукта. • Нельзя приступить к тестированию раньше, чем продукт будет к нему готов. Проблема в том, что, если проектирование и кодирова ние продукта затянется, тестирование тоже будет начато позже сро ка. Поэтому следует тщательно продумать свои действия в такой ситуации. Во-первых, вы отвечаете за то, чтобы сформированная группа квалифицированных тестировщиков не простаивала. С одной стороны, она должна приступить к работе, как только продукт бу дет готов. С другой стороны, если программа не будет достаточно стабильна, ее придется вернуть программистам на доработку, а те- стировщиков загрузить другой работой, которая позволит ускорить |