Как оценивать размер тестовых кейсов и их количество
Что проверяют
Умеете ли вы обосновать число тестов техниками тест-дизайна и рисками, а не называть его на глаз. Второе, что смотрят: понимаете ли вы, каким должен быть один кейс, чтобы его было удобно поддерживать. Следом часто просят оценить трудозатраты на тестирование фичи.
Как отвечать
Количество выводится из техник, а не придумывается:
- классы эквивалентности и граничные значения: для поля от 1 до 100 проверяются 0, 1, 100, 101 и одно значение из середины, а не сто чисел;
- попарное тестирование (pairwise): три параметра по три значения дают 27 полных комбинаций, а все пары покрываются девятью. Такие наборы генерируют утилиты вроде PICT;
- таблицы решений и диаграммы состояний: для бизнес-правил и статусных моделей число кейсов равно числу правил или переходов;
- риски: критичные и часто меняющиеся модули получают больше негативных и регрессионных кейсов, редкие сценарии закрываются чек-листом;
- трассировка: матрица требований показывает пробелы, где к требованию не привязан ни один кейс.
Размер кейса: одна цель проверки, явные предусловия, обычно до десятка шагов и один ожидаемый результат, который однозначно даёт «прошёл» или «упал». Кейс не зависит от других и не ломается от порядка запуска.
Трудозатраты считают от количества: число кейсов, среднее время на прогон по истории из TestRail или Qase, плюс подготовка данных, повторные проверки и регресс. Для неясных задач помогает трёхточечная оценка.
Где спотыкаются
Называют число без техник: «по пять кейсов на требование». Интервьюер тут же спросит, откуда пять.
Считают, что 100% покрытия требований означает хорошее тестирование. Матрица говорит лишь, что к каждому требованию привязан кейс, а не что проверены границы и негативные сценарии.
Пишут сквозные кейсы на тридцать шагов. Такой кейс падает на пятом шаге, остальное остаётся непроверенным, а по отчёту не понять, что именно сломалось.