Из собственного опыта написания и обучения написанию тест кейсов, получилось несколько правил
:
1. Каждый тест кейс должен быть независимым от другого, т.е. в тест кейсе не должно быть ссылок на другие тест кейсы.
Например:
Есть тест кейс "TC1 - Сохранение документа в формате txt" и мы пишем другой тест кейс.
Неверно: Шаг1. Проити тест кейс "TC1 - Сохранение документа в формате txt"
Понятно, что при прохождении этого тест кейса необходимо будет отвлечся и найти его пройти а потом вернуться. При этом дважды теряется фокус внимания.
Есть вариант делать, этот шаг ссылкой на другой тест кейс, но тут могут возникнуть трудности в сапорте таких тест кейсов. Нужно будет хранить и отслеживать все зависимости и их изменения.
Верно:
Pre-condition: Документ сохранен в формате txt.
Можно вынести в предусловия (если это не является частью проверяемой функциональности)
или
Шаг1: Сохраните документ в формете txt.
Но в обоих случаях подразумивается, что известно как сохранить документ в формат txt.
По сути считаем, что если человек прошел тест кейс "TC1 - Сохранение документа в формате txt", то он знает как сохранить документ в формат txt.
Такой подход помогает при организации тестировании, от меньшего к большему, а также при ознакомлении новых кадров с проектом.
2. Шаг в тест кейсе должен однозначно определять "Что делать" и "Что должно получится".
2.1 Описание шага не должно содержать конструкций типа:
а) Шаг1. Введите в поле значение А или В
Если имеет значение вводимый элемент пишем два тест кейса. Если Важен класс, то указываем только его, т.е. введите в поле один символ (a-z).
б) Посторите шаг4-шаг5
При ссылки на другие шаги теряется фокус, и прохождение тест кейса занимает большее время. Также теряется часть внимания, и мы рискуем пропустить ошибку.
2.2. В описании результата не должно содержать конструкции типа:
а) Выберите txt файл -> Если выбрали файл больше 1024 kb, то диалоговое окно закрылось, иначе получили сообщение об ошибке.
Пишем два тест кейса на выбор файла больше и меньше нужного размера.
3. Имя тест кейса уникально для проекта и несет в себе описание тестируемой функциональности.
Кстати , неплохой способ проверить тест кейс на качество детализации и названия. Представте, что тест кейс сфейлился на шаге, это значит что проверяемая функциональность не работает.
4. В одном тест кейсе проверяется только одна функциональность.
Например в тест кейсе, который проверяет работу поиска, не нужно описывать все методы открытия окна поиска.
Нужно проверить именно работу поиска, рассмотрев случаи, когда результат поиска положительный, а когда отрицательный.
Плюс тест кейсы на работу всех методов открытия окна поиска.
В принципе это все.
If I can see it, it's a failure.