Сколько тест кейсов нужно для одного требования?

Сколько тест-кейсов нужно для одного требования?

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

Прямой ответ "один тест-кейс на требование" или "три тест-кейса" был бы неверным. Вместо этого я бы структурировал свой ответ, демонстрируя системный подход.

Факторы, влияющие на количество тест-кейсов

Объяснив, что число вариативно, я бы перечислил ключевые факторы, которые я анализирую:

1. Сложность и детализация требования (Atomicity).

    *   **Элементарное требование:** "Кнопка 'Отправить' должна быть синего цвета". Здесь достаточно 1-2 тест-кейсов (проверка видимости, соответствия цвета).
    *   **Сложное требование:** "Пользователь может восстановить пароль, указав email, на который придет ссылка с токеном, действительным 24 часа". Для него понадобится целый набор кейсов, покрывающих:
        *   Позитивные сценарии (валидный email, переход по ссылке).
        *   Негативные сценарии (несуществующий email, некорректный формат, истекший токен, повторное использование токена).
        *   Граничные условия и безопасность.

1. Применяемые техники тест-дизайна.

    Это основной инструмент для определения **минимального достаточного набора** тестов.
    *   **Эквивалентное Разделение (Equivalence Partitioning):** Группирует входные данные в классы. Для поля "Возраст (18-99)" это создаст классы: `<18`, `18-99`, `>99`. Минимум 3 теста.
    *   **Анализ Граничных Значений (Boundary Value Analysis):** Добавит тесты для значений на границах: 17, 18, 99, 100. Итого может получиться 5-7 тестов.
    *   **Таблица Решений (Decision Table):** Если требование описывает сложную бизнес-логику с условиями (например, "скидка применяется, если клиент постоянный И сумма заказа >1000 ИЛИ есть промокод"), таблица решений систематически выявит все комбинации условий и действий, что может дать 5-10+ тест-кейсов.
    *   **Диаграмма Переходов Состояний (State Transition):** Для требований, где важен порядок действий (например, статус заказа: Новый -> Оплачен -> Отгружен -> Доставлен), эта техника поможет протестировать все валидные и невалидные переходы.

1. Уровень тестирования и приемочные критерии.

    *   На **юнит-уровне** разработчик может написать десяток тестов для одной функции.
    *   На **интеграционном уровне** фокус смещается на взаимодействия.
    *   На **уровне приемки (UAT)** может быть всего 1-2 высокоуровневых тест-кейса, которые подтверждают, что требование реализовано с точки зрения бизнес-ценности.

1. Приоритет и риски.

    Для критичного для бизнеса или связанного с безопасностью требования я запланирую более тщательное, "глубокое" покрытие (больше тестов). Для тривиальной или маловероятной функции — достаточно базового позитивного и ключевых негативных сценариев.

Практический пример и расчет

Допустим, есть требование: "Поле 'Количество товаров' принимает целые числа от 1 до 10".

Используя техники тест-дизайна, я могу рассчитать примерное количество:

// Пример логики, которую мы тестируем (не тест-кейс!)
public boolean validateQuantity(int quantity) {
    return quantity >= 1 && quantity <= 10;
}

Анализ:

1. Эквивалентные классы:

    *   Валидный класс: 1, 2, ..., 9, 10.
    *   Невалидный класс "маленький": 0, -1, -100...
    *   Невалидный класс "большой": 11, 100...

1. Граничные значения: 0, 1, 2, 9, 10, 11.
2. Дополнительно: Пустое поле, нечисловые символы, дробные числа (зависит от деталей).

Итоговый набор тест-кейсов может выглядеть так (пример 7-9 кейсов):

• TC-POS-1: Ввод 5 -> Успех.
• TC-BVA-1: Ввод 1 (нижняя граница) -> Успех.
• TC-BVA-2: Ввод 10 (верхняя граница) -> Успех.
• TC-NEG-1: Ввод 0 (ниже границы) -> Ошибка.
• TC-NEG-2: Ввод 11 (выше границы) -> Ошибка.
• TC-NEG-3: Ввод -5 -> Ошибка.
• TC-NEG-4: Ввод "abc" -> Ошибка.
• TC-NEG-5: Оставить поле пустым -> Ошибка (или специфичное сообщение).

Мой подход как Senior QA

1. Сначала анализ, а не счет. Я начинаю не с вопроса "сколько?", а с вопросов: "Что мы тестируем?", "Какие риски?", "Какая техника дизайна здесь наиболее эффективна?".
2. Оптимизация и достаточность. Я стремлюсь не к максимальному, а к оптимальному количеству. Цель — найти дефекты с минимальным, но эффективным набором тестов, используя техники, упомянутые выше.
3. Фокус на качестве, а не на количестве. Один хорошо продуманный тест-кейс, использующий технику анализа граничных значений, ценнее десяти поверхностных. Я всегда проверяю не только "работает ли", но и "ломается ли правильно" (обработка ошибок).
4. Покрытие требований vs. покрытие кода. Количество тест-кейсов должно гарантировать, что требование полностью покрыто (все условия, бизнес-правила, варианты использования). Инструменты покрытия кода (code coverage) могут помочь выявить недостатки, но 100% coverage не равно качеству тестов.

Вывод: Для одного требования может потребоваться от одного до двадцати и более тест-кейсов. Ключевой навык — это умение обосновать выбранный объем тестирования, исходя из анализа требования, применения современных техник тест-дизайна и оценки рисков. На собеседовании я бы показал именно этот аналитический процесс, а не назвал бы магическое число.