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

Глава 14. Управление группой тестирования

Приложение. Распространенные

программные ошибки

Глава ш

Объединяющая

Назначение этой главы

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

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

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

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

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

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

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

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

Обзор

В данной главе рассматриваются следующие вопросы:

• Чем приходится поступаться при разработке программного обеспечения

• Модели разработки

• Затраты, связанные с качеством продукта

• Сроки разработки

• Проект продукта

• Анализ пользовательских данных

• Первоначальная функциональность

• Почти альфа

• Альфа