Составь сценарии тестирования веб-приложения оформления отпуска с бизнес-правилами
Что проверяют
Не длину списка кейсов, а подход. Формулировка «с бизнес-правилами» намекает, что правила вам не выдали целиком, и первым делом ждут уточняющих вопросов, а потом уже техник тест-дизайна и расстановки приоритетов.
Как отвечать
Начать с вопросов. Какие роли участвуют: сотрудник, руководитель, кадровик. Какие типы отпуска и у каждого ли свои правила. Откуда берётся остаток дней и пересчитывается ли он при отзыве заявки. Сколько ступеней согласования и что происходит при отказе на второй. Как учитываются праздники и переносы. Можно ли оформлять задним числом. Проверяется ли пересечение с отпусками коллег. Куда уходят данные дальше, в расчёт зарплаты или в кадровую систему.
Дальше техники. Классы эквивалентности по остатку дней, граничные значения по датам: сегодня, вчера, первый и последний день периода, конец года, февраль. Таблица решений для комбинаций правил согласования. Диаграмма состояний заявки: черновик, на согласовании, согласована, отклонена, отозвана, отменена, и проверка запрещённых переходов. Попарные комбинации типа отпуска, роли и остатка. Отдельно права доступа, чужая заявка по прямой ссылке, одновременная подача двух заявок на одни даты, часовые пояса и журнал изменений.
Где спотыкаются
Сразу пишут шаги позитивного сценария и по дороге придумывают правила вроде «не больше тридцати дней». Придуманное ограничение проверять бессмысленно, а сам факт, что кандидат не спросил, и есть результат этого вопроса.
Описывают только путь через интерфейс. Ограничение, реализованное выбором дат в календаре, обходится прямым запросом к API, поэтому каждое бизнес-правило нужно проверять и на сервере тоже.
Не трогают состояния и параллельность: согласование заявки, которую сотрудник уже отозвал, двойное нажатие кнопки отправки, два руководителя, нажавшие согласовать одновременно. Именно там живут настоящие дефекты таких систем.