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

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

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

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

Когда вы сложите время всех предложенных в ходе обсуждения задач, результат окажется огромным. Он может в 5 или 10 раз превышать запла­нированную длительность всего проекта. Это нормально. А вот если ока­жется, что предполагаемые работы по тестированию прекрасно укладываются в график проекта, тогда стоит обеспокоиться.

Теперь, имея четкий список задач, можно приступать к принятию ре­шений.

• Выделите задачи, которые не могут быть выполнены.

• Распределите приоритеты между остальными.

• Решите, какие из задач будут выполнены только частично и какие это будут части. (При этом, выбирая тесты, вы в одних случаях будете полагаться на логику, а в других действовать методом случай­ного отбора.)

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

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

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

Классификация проекта

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

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

• Затем сделайте предположения о том состоянии, в котором про­дукт попадет вам в руки. Снова воспользуйтесь трех- или пятибал­льной шкалой. Сколько ошибок предполагается найти в программе? В программах одних руководителей проектов больше ошибок, чем в программах других. То же самое относится и к программистам. Если в давно работающую программу вносится всего несколько исправ­лений, ошибок будет не много. Если же разрабатывается самый первый выпуск сложного продукта, он будет полон ошибок.

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

		Ожидаемая надежность
		Высокая	Средняя	Низкая
Сложность проекта	Низкая	1	4	16
	Средняя	4	16	64
	Высокая	16	64	256

РИСУНОК 14.1. Таблица гипотетических оценок стоимости работ