Планы тестирования — это самые ранние продукты тестирования, которые появляются и о которых также первыми забывают.

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

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

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

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

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

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

Вот некоторые функции, которые мы хотим, чтобы наш план тестирования имел

Обновляйте своевременно.

Описывает цели и преимущества программного обеспечения.

Описывает структуру программного обеспечения, названия его различных компонентов и функциональных особенностей.

Описывает введение в функциональные возможности и работу программного обеспечения.

С точки зрения чистого тестирования, нас беспокоит, совпадают ли входные и выходные значения плана тестирования.

Написание не должно занимать слишком много времени, его необходимо иметь возможность изменить в любое время.

Должны быть описаны точки, которые необходимо измерить.

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

Руководящая идеология плана тестирования

Избегайте бессвязного текста:

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

Не нужно рекламировать:

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

краткий:

Требований к продолжительности плана тестирования нет. Это не проект средней школы, где длина не имеет значения: длиннее не всегда лучше. Размер плана зависит от размера тестового вопроса, а не от желания автора писать.

Не добавляйте в план тестирования неважные и неисполняемые вещи:

Даже не говорите ни слова о том, что не волнует вовлеченных людей.

Прогрессивное описание:

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

Идеи, которыми можно руководствоваться при планировании:

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

Конечным результатом должен быть тестовый пример:

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

Для планирования тестирования это, очевидно, должно дать нам четкое представление о том, какие тестовые примеры необходимо написать. План тестирования считается завершенным, когда вы полностью понимаете, какие тесты необходимо написать.。