Расскажите про самый сложный тестируемый кейс в вашем опыте

Что проверяют

Умеете ли вы тестировать то, что плохо поддаётся проверке. Вопрос про сложный кейс это вопрос про тест-дизайн там, где очевидного сценария нет: недетерминированное поведение, много состояний, внешние системы, которыми вы не управляете. Интервьюер хочет увидеть, как вы сужаете бесконечное пространство вариантов до проверяемого набора.

Как отвечать

Берите кейс, где сложность была в природе задачи. Типичные примеры: гонка при одновременных действиях двух пользователей, повторная отправка запроса там, где речь о деньгах, обрыв связи посреди операции, миграция данных с проверкой состояния до и после, интеграция с внешним сервисом без тестового контура.

Разворачивайте так:

• почему обычные проверки не работали: результат зависел от времени, состояние копилось между шагами, воспроизведение занимало часы;
• как свели к проверяемому: классы эквивалентности, границы, таблица решений, попарное покрытие вместо перебора комбинаций;
• чем управляли окружением: заглушки вместо внешнего сервиса, подмена времени, генерация данных, подготовка состояния напрямую в базе;
• что нашли и как оформили, чтобы разработчик воспроизвёл с первого раза.

Отдельный плюс, если расскажете, как защитили найденное от повторения: проверка ушла в регресс или в автотест на уровне API, а не осталась в голове.

Где спотыкаются

Называют сложным кейс, который был просто длинным. Сценарий на сорок шагов это трудоёмкость, а не сложность, и обычно такой сценарий стоило разбить на несколько.

Второе: описывают дефект, а не тестирование. Интервьюер спросил, как вы к нему пришли, а слышит подробный рассказ о том, что именно сломали разработчики.

Третье: не говорят про воспроизведение. Плавающий дефект без выясненных условий возвращается с пометкой «не воспроизводится», и это чаще проблема тестировщика, чем разработчика.