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

К сожалению, здесь же имеется и целый ряд проблем.

• Неопытные тестировщики (включая и многих достаточно опыт­ных программистов) — это плохие тестировщики.

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

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

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

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

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

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

• Четкие пошаговые инструкции для выполнения теста. Его испол­нитель не должен догадываться, что и как делать, это должно быть совершенно четко записано в инструкции.

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

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

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

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

Заметки для руководителя

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

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

• Имя или номер, однозначно идентифицирующие тест.

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