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

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

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

• Длительность типичного цикла тестирования. Этот показатель имеет смысл только тогда, когда каждая версия программы или определенной ее части всегда проходит полный цикл тестирования. Если же новая версия программы поступает каждую неделю незави­симо от того, насколько протестирована предыдущая, данная оцен­ка теряет смысл.

• Количество ошибок, документируемых за день одним тестировщи­ком. Если один тестировщик находит за день в среднем 5 ошибок и вы предполагаете, что всего в программе их будет найдено около 1000, значит, на ее тестирование потребуется 200 человеко-дней.

• Время тестирования одного устройства. При этом время настройки устройства следует учитывать отдельно.

• Количество страниц документации, проверяемых за один час.

Конечно, это время зависит от типа документации и целей ее проверки.

• Количество сообщений об ошибках, тестируемых за один час.

Сколько времени займет тестирование всего блока обработки оши­бок?

• Часть (количество страниц) плана тестирования, выполняемая за один час. Сколько времени уйдет на выполнение всего плана?

Можно придумать и множество других примеров. Целый ряд показате­лей продуктивности программного обеспечения приводит в своей книге Джонс (Jones, 1991).

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

Статистические данные о производительности персонала полезны, но только при правильном употреблении. Если вы попытаетесь использовать

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

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

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

Определение и оценка каждой задачи

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

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

Возьмите лист бумаги, запишите на нем все основные задачи тестиро­вания и прикрепите его к стене. У вас может получиться 5, 10 или 20 крупных задач — едва ли больше. Затем для каждой из основных задач перечислите на отдельном листе бумаги все ее составляющие. Эти листы также развесьте по стенам. Некоторые из подзадач могут оказаться настоль­ко сложны, что потребуют дальнейшего разбиения. Их составляющие тоже перечислите на отдельных листах. Придумав еще одну базовую задачу, вы будете дописывать ее в главный список, а затем брать новый лист бумаги и перечислять на нем все ее составляющие.

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

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