Тест-кейсы: структура, составление и приоритизация
Структура тест-кейса
Стандартный тест-кейс включает:
- ID – уникальный идентификатор
- Название – краткое описание цели
- Предусловия – необходимые условия для выполнения
- Шаги – последовательные действия
- Ожидаемый результат – что должно произойти при корректной работе
- Фактический результат – заполняется при выполнении
- Статус – пройден/не пройден/заблокирован
- Приоритет – важность тест-кейса
- Окружение – версии ОС, устройства, браузеры
Правила составления
- Атомарность – один тест-кейс проверяет одну функцию/сценарий
- Однозначность – исключение двусмысленных формулировок
- Воспроизводимость – тест-кейс должен давать одинаковый результат при многократном выполнении
- Независимость – минимальная зависимость от результатов других тест-кейсов
- Конкретность – точное описание шагов и ожидаемых результатов
- Полнота – достаточно информации для выполнения тестировщиком без дополнительных консультаций
Приоритеты тест-кейсов
Типичная градация приоритетов:
- Критический (Critical/P0) – блокирующие функциональность проблемы, влияющие на базовые возможности
- Высокий (High/P1) – серьезное влияние на ключевые функции
- Средний (Medium/P2) – заметные, но не критичные проблемы
- Низкий (Low/P3) – минимальное влияние на пользовательский опыт
Кто устанавливает приоритеты
Приоритеты устанавливаются совместно:
- QA-инженер – предлагает начальный приоритет на основе своей оценки
- Product Owner/Manager – определяет бизнес-важность функциональности
- Scrum Master/Project Manager – учитывает сроки и ресурсы
- Технический лид/Team Lead – оценивает техническую сложность и риски
Окончательные приоритеты часто определяются на грумингах или планировании спринта, где все заинтересованные стороны могут высказать свое мнение. В итоге решающее слово обычно остается за Product Owner.