Перед тем как приступать к написанию любого тест-плана, необходимо задуматься о конечной цели. Насколько детализированным должен быть тест-план? Какие виды граничных условий должны быть проверены? Какие существуют потенциальные риски неизвестных дефектов? Ответы на эти вопросы будут сильно различаться в зависимости от того, тестируете ли вы детскую онлайн-игру или же программу для мониторинга ядерного реактора. В зависимости от контекста и области тестируемого программного обеспечения даже для программ со схожими требованиями могут понадобиться различные стратегии создания тест-планов.
Простейший — и зачастую лучший — путь разработки детализированного тест-плана заключается в чтении требований и определении того, как их можно протестировать по отдельности. Обычно довольно много мыслей вкладывается в разработку требований, и поскольку целью системы является удовлетворение требований, имеет смысл убедиться, что все требования были реально протестированы. Это также открывает простой путь к созданию тест-плана. Итак, первое требование — напишем тест-кейсы; второе требование — напишем еще тест-кейсы; и будем повторять до тех пор, пока все требования не будут покрыты.
Для каждого требования необходимо продумать хотя бы один "счастливый путь" и создать хотя бы один тест-кейс для этого пути. То есть надо определить, в какой ситуации при рабочих параметрах будет удовлетворено это требование? Например, если у вас есть требование, чтобы некая кнопка была доступна для нажатия, только если значение меньше 10, и недоступна, если 10 и больше, то минимально вам понадобится создать тесты, проверяющие, что кнопка активна, если значение меньше 10, и неактивна, если значение больше либо равно 10. Этим тестируются оба класса эквивалентности требования (значение < 10 и значение ≥ 10).
Вы также можете продумать случаи, в которых помимо классов эквивалентности тестируются различные граничные условия. Продолжая рассматривать вышеприведенный пример, давайте предположим, что у вас есть тест-кейсы для значения 5 и для значения 15, что гарантирует вам использование по крайней мере одного значения для каждого класса эквивалентности. Если вы захотите добавить тест-кейсы, проверяющие границу между двумя классами эквивалентности, можете добавить тест-кейсы для 9 и 10.
Сколько таких граничных и угловых кейсов вы добавите и насколько широко вы протестируете внутренние и граничные значения, будет зависеть от времени и ресурсов, которые у вас есть для тестирования, от области ПО и уровня риска, который допустим для вашей организации. Помните, что исчерпывающее тестирование во всех отношениях невозможно. Существует скользящая шкала времени и энергии, которые можно потратить на написание и исполнение тестов, и не существует правильного ответа, что именно нужно выбрать. Нахождение компромисса между скоростью разработки и обеспечением качества является одной из ключевых задач тестировщика программного обеспечения.
Создание тест-кейсов для нефункциональных требований (атрибуты качества) к системе зачастую может быть сложным. Вам следует попытаться убедиться, что требования сами по себе являются тестируемыми, и оценить количество тесткейсов, которые нужны для этих требований.
К сожалению, просто наличие соответствия между требованиями и тест-кейсами для каждого их них не всегда означает, что вы разработали хороший тест-план. Вам, возможно, потребуется добавить дополнительные тесты, чтобы убедиться, что требования работают в тандеме, или проверить с точки зрения пользователя те ситуации, которые не связаны напрямую с требованиями или не вытекают из них. Более того, вам необходимо научиться понимать контекст, в котором существует программа. Обладание профильными знаниями в области работы поможет вам понять основные рабочие ситуации, то, как система взаимодействует с внешним миром, возможные проблемы, и как пользователь может ожидать восстановления системы после возникновения этих проблем. Если никто в команде не понимает область работы программы, возможно, следует обсудить вопросы со специалистом (subject matter expert, SME) перед написанием тест-плана.
Понимание программной среды, в которой создается ПО, также может способствовать написанию тест-плана, хотя технически это приведет к тестированию серого ящика, в отличие от тестирования черного ящика, потому что вы, как тестировщик, будете знать некоторые особенности внутренней реализации, но это может дать ценное понимание того, где могут скрываться потенциальные ошибки. Позвольте мне привести пример. В Java деление на ноль, как показано ниже, выбросит исключение java.lang.ArithmeticException:
int a = 7 / 0;
Не имеет значения, какое у нас делимое, потому что если делитель равен нулю, выбрасывается исключение java.lang.ArithmeticException:
// Во всех этих случаях выбрасывается одно и то же исключение
int b = -1 / 0;
int c = 0 / 0;
int d = 999999 / 0;
Следовательно, при тестировании написанной на Java программы вы можете предположить, что деление на ноль, по существу, является одним классом эквивалентности; если это произошло, то затем будет происходить одно и то же событие, каким бы оно ни было (например, возможно, что исключение перехвачено и сообщение "Ошибка деления на ноль" выведено в консоль).
JavaScript (да, технически я имею в виду ECMAScript 5 — для тех, кто хочет знать подробности) не выбрасывает исключение во время деления на ноль. Однако если знаменатель равняется нулю, то в зависимости от числителя вы можете получить разные результаты!
> 1 / 0
Infinity
> -1 / 0
-Infinity
> 0 / 0
NaN
Деление положительного числа на ноль возвращает бесконечность, деление отрицательного числа — "минус" бесконечность, а деление нуля на ноль — NaN (Not a Number — не число). Это означает, что деление на ноль, несмотря на то, что является одним "внутренним классом эквивалентности" для Java-программ, оказывается тремя разными классами для программ, написанных на JavaScript. Зная это, вы, возможно, захотите протестировать программу и убедиться, что она может обработать все эти возвращаемые значения, и не предполагать, что вы проверили все граничные случаи просто потому, что вы проверили деление на ноль. Это реальный пример из написанного мною тест-плана, и при его использовании было найдено несколько дефектов.