Еще правила, которых нужно придерживаться

§ необходимо в каждом тесте уделять внимание процедуре приведения объекта тестирования в некую исходную позицию до прохождения теста и, если это рационально, его возврата в эту же позицию после прохождения теста — это дает возможность запускать тесты независимо, в любом нужном порядке, не заботясь о том, в каком состоянии объект остался после предыдущего теста;

§ при этом следует определить оптимальные стартовые позиции/состояния объекта тестирования для всех тестов, чем их получится меньше, тем лучше (меньше усилий и времени для подготовки объекта к новому тесту и больше удобства при группирования тестов);

§ количество шагов нужно оптимизировать, иногда в одном шаге можно объединить несколько, если нам важен промежуточный результат только последнего из них, однако, если уверенности нет, лучше описать лишнее, чем пропустить ключевой шаг;

§ упорядочивать тесты в тест-плане желательно последовательно по отношению к функциональности объекта тестирования, двигаясь от тестов первых действий или экранов объекта (например, запуска самой программы) до последних (например, ее закрытия);

§ тестер не должен придумывать спецификации и термины, которые нигде пока не описаны и не применяются в требованиях, не должен использовать условности из своей жизни (например, «phone receives the call» не обязательно соответствует фразе «телефон звонит», а «open the door» не всегда означает, что дверь открывается именно поворотом ручки), такое придумывание может привести к написанию неверных тестов;

§ раздел тест-плана «Open Issues» (открытые вопросы, нюансы) используется для того, чтобы собрать в одном месте отсутствующие в требованиях данные, запросы на уточнения, без которых нельзя написать некоторые тест-кейсы;

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

Общие разделы

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

§ описание документа (document description), зачем и для кого он нужен, к чему имеет отношение —
в нашем случае там описывается следующее: вкратце об объекте тестирования (object of testing); список родственных документов (related documents), в нем как минимум ссылка на Требования и Тест-отчеты; глоссарий (glossary) — расшифровка терминов и обозначений; указание границ, глубины документа (scope) — что документ описывает хорошо, что лишь упоминает, а что не описывает вообще (например, он может не описывать подробно все параметры функций и не содержать историю версий продукта, в этом случае будет уместна ссылка на документ, который описывает упущенное лучше); открытые вопросы (open issues), которые нужно обсудить и определить до такого-то этапа тестирования;

§ условия тестирования (test conditions) — обычно это программная (software) и аппаратная (hardware) конфигурация, при которой данный тест-план считается верным и годным к применению, и ограничения (restrictions), сужающие область ответственности для данной версии тест-плана (например, следующие версии продукта не могут быть протестированы некоторой частью тестов);

§ другие особенности тестирования (other issues), здесь уместно упоминание об используемой системе регистрации и ведении истории найденных в процессе тестирования ошибок (bug tracking system) и еще каких-то относительно важных моментов;

§ список функциональности, которая не будет протестирована вообще (not to be tested) и почему (чаще всего это идентификаторы Требований, которые не поддаются покрытию тестами или поддаются слишком трудно, что делает нерациональным их покрытие);

§ возможны другие разделы, например, отказ от ответственности (disclaimer), копирайт (авторские права) и прочее.

Описание тестов, разделение их на группы (тест-сьюты)

Это самая важная часть документа, а точнее, он сам и есть. Здесь после возможного вступления, разъяснения принятого стиля описания тестов и находится весь набор тестов, разделенный на тест-кейсы (test cases) и тест-сьюты (test suites).

Последнее понятие применяется в случае, если набор всех тест-кейсов планируется разделить на отдельные группы (сьюты), а не проходить каждый раз все тесты подряд. Например, имеет смысл создать тест-сьют для быстрого тестирования самой важной функциональности (sanity testing suite) с целью быстро оценить стабильность новой сборки, для стрессового тестирования (abusive или stress testing suite) и другие сьюты, подходящие для конкретной ситуации с конкретным объектом тестирования.

В некоторых случаях тест-сьюты могут содержать так называемые случаи применения (use cases) — это как правило комплексные тест-кейсы высокого уровня, то есть, реальные случаи применения продукта пользователем, описание целой процедуры работы с отдельной функцией продукта тестирования, а не проверка отдельного элемента этой функции. Например, если объект тестирования — телефонный терминал, то совершить звонок (дозвониться, побыть в состоянии соединения, закончить звонок) — это случай применения (use case), а убедиться, что при «поднятии» трубки слышен гудок или включается подсветка клавиатуры, — это тестовый случай (test case), то есть, тестирование системы на низком уровне, а не на пользовательском.

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

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

Поиск по сайту: