Проектирование Тестового случая - рекомендации
Всем привет!
Сегодня я хочу поделиться с вами своими рекомендациями касаемо проектирования Тестовых случаев.
Тестовый случай - это некоторый артефакт тестирования, содержащий шаги, которые необходимо выполнить, их ожидаемые результаты и условия, при выполнении которых можно сделать вывод о том, что тестируемая функциональность реализована согласно требованиям.
Тестовые случаи могут быть позитивными и негативными. Позитивный Тестовый случай содержит сценарий ожидаемых действий пользователя в системе, в то время как негативный Тестовый случай предполагает, что пользователь может совершить ошибку (намеренно или нет), в этом случае система должна повести себя корректно (что, собственно, и тестируют негативные ТС).
В своих предыдущих статьях (тут и тут) я уже рассказывала о ТС как, с одной стороны, об артефакте тестирования, с другой - Рабочем элементе типа "Тестовый случай" в рамках используемого программного инструмента, сопровождающего (в частности) процесс тестирования - Test Hub TFS и/или MTM. Вы можете не использовать специализированный инструмент, позволяющий создавать Тестовые случаи (для этих целей вы можете использовать, например, ЭТ Excel или обычный Блокнот). Однако, подходить к процессу проектирования Тестового случая нужно очень серьезно - хорошо спроектированный ТС будет выполнять свою функцию на высоком уровне, в отличие от ТС, к проектированию которого отнеслись не очень серьезно (такой ТС может быть вообще бесполезным).
Как правило, хороший Тестовый случай имеет следующую структуру: Precondition → Steps → Post Condition.
Шаг Тестового случая, в свою очередь, имеет вид: Action → Expected Result (→ Test Result). Test Result - это часть, которая появляется в структуре шага, только когда мы непосредственно выполняем Тестовый случай, а значит, можем присвоить ожидаемому результату (Expected Result) один из статусов - Passed или Failed. В рамках проектирования Тестового случая эту часть мы не учитываем.
Не все шаги Тестового случая обязаны иметь ожидаемые результаты (как проверки промежуточных состояний системы). Однако, последний шаг Тестового случая, ожидаемым результатом, как правило, имеет проверку целевой функциональности.
Шаг Тестового случая и его ожидаемый результат должны быть сформулированы крайне четко!
Структура - это лишь внешний критерий. Вся суть - в содержании.
Проектирование Тестовых случаев - это роль, которую могут выполнять только тестировщики высокой квалификации, способные правильно интерпретировать Требования (Пользовательские истории), разработать стратегию тестирования согласно Требованиям и воплотить ее в четкой последовательности действий и их результатов. Если таких Требований нет (а это, к сожалению, довольно частая практика), то это налагает еще большую ответственность - качество Тестовых случаев напрямую будет зависеть от профессионализма тестировщика и его знаний. Кроме того, его контакты с руководителем проекта и разработчиками будут еще более частыми. Если не хотите переделывать Тестовые случаи в будущем - не назначайте задачу по проектированию Тестовых случаев человеку с низкой квалификацией (например, из-за нехватки ресурсов).
Из своего опыта дам еще одну рекомендацию к оформлению Тестового случая - необходимо разработать четкие шаблоны (вплоть до устойчивых конструкций часто используемых формулировок шагов и ожидаемых результатов, используемого шрифта и его размера, принципов формирования заголовков и т.д.). В случае, когда проектированием Тестовых случаев занимается несколько человек и между ними нет никаких договоренностей - это приводит к "разношерстным" Тестовым случаям, каждый пишет как может. Прибавьте к этому недостаточную квалификацию. А теперь представьте, что заказчик захотел увидеть ваши планы тестирования...
Кроме того, необходим постоянный контроль за существующими в системе Тестовыми случаями. Всегда можно сказать - "У нас есть Тестовые случаи, их почти 1000!", и это может быть правдой. А что насчет их качества? В актуальном ли они состоянии? Запускаются ли эти ТС или они просто существуют в системе? И самый важный вопрос - помогают ли они находить ошибки? Я являюсь сторонником идеи, когда имеется роль "надзирателя". Сначала он сам проектирует и создает Тестовые случаи, составляет рекомендации, а затем обучает тестировщиков и выполняет мониторинг. Первое, за каждый Тестовый случай, зарегистрированный в системе, кто-то должен нести ответственность, и, второе, каждый Тестовый случай должен работать, всегда быть в актуальном состоянии и находить ошибки.
Всем добра и до скорой встречи!
Комментарии
Отправить комментарий