Какие кейсы проверялись
Что проверяют
Вопрос обычно звучит после рассказа о проекте: интервьюер хочет понять, доводите ли вы требования до проверки или передаёте их тестированию и забываете. Следом спрашивают, откуда брались кейсы и что вы делали, когда результат расходился с требованием.
Как отвечать
Это вопрос про ваш опыт, поэтому нужны свои примеры. Каркас удобно строить так: какая была фича, на основании чего писали кейсы, какие группы проверок покрыли, что нашли.
- по критериям приёмки: каждому критерию из пользовательской истории соответствует хотя бы один сценарий. Удобно формулировать в Gherkin:
Given,When,Then; - бизнес-правила: расчёты, статусы и переходы между ними, ограничения. Например, заявку в статусе «Отклонена» нельзя отправить повторно;
- негативные и граничные случаи: пустые и неверные значения, пороги сумм и дат, превышение лимитов;
- роли и права: что видит и может сделать каждая роль, особенно запреты;
- интеграции: что уходит во внешнюю систему, что приходит обратно, как ведёт себя процесс при ошибке или таймауте. Здесь аналитик часто сам смотрит запросы в Postman или Swagger UI, а данные проверяет SQL-запросом;
- приёмочное тестирование (UAT): сценарии для бизнес-заказчика на языке процесса, а не полей.
Хорошо упомянуть матрицу трассируемости: связь требования, кейса и результата в Jira, TestIT или другой системе управления тестами. Цифры приводите только реальные: сколько сценариев, сколько дефектов нашли до релиза. Если сами кейсы вы не писали, скажите честно и расскажите, как проверяли, что тестировщики поняли требования: ревью их чек-листов, разбор спорных сценариев.
Где спотыкаются
Отвечают общими словами «проверяли основной функционал». Без конкретной фичи и хотя бы одного правила ответ не засчитывают.
Рассказывают STAR-историю с красивыми процентами, которые не могут объяснить. Уточняющий вопрос «как считали эти 20%» такую историю разрушает.
Описывают только позитивный сценарий. Для аналитика ценнее всего показать, что он заранее продумал исключения и ошибки интеграции.