Как протестировать модуль

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

Есть ли у вас порядок действий, когда задача сформулирована расплывчато. Сильный кандидат сначала задаёт вопросы, потом строит проверки от рисков. Следом обычно спрашивают: «а если требований нет?» или «что из этого вы бы автоматизировали?».

Как отвечать

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

• границы: что на входе и на выходе, с какими модулями и внешними сервисами он общается, есть ли требования, макеты, контракт API. Без документации источником становятся разработчик, аналитик и текущее поведение;
• уровни: компонентное тестирование модуля в изоляции, где соседей заменяют заглушки, затем интеграция с реальными соседями и в конце сквозные сценарии через интерфейс. Юнит-тесты пишут разработчики, но знать их покрытие полезно;
• тест-дизайн: классы эквивалентности и граничные значения для полей, таблицы решений для комбинаций условий, диаграмма состояний для сущностей со статусами (ссылка выдана, использована, истекла), pairwise, когда параметров много;
• негатив и нефункциональное: неверные данные, повтор операции, отказ смежного сервиса, безопасность (перебор, повторное использование токена), производительность, если модуль под нагрузкой;
• приоритеты: сначала smoke и критичный путь, затем остальное по риску. Что дороже всего сломается, то и проверяется первым;
• артефакты: чек-лист или тест-кейсы в TMS (TestIT, Qase, TestRail), дефекты в трекере с шагами и окружением;
• регрессия: стабильные и часто повторяемые проверки уходят в автотесты, лучше на уровне API, чем через UI.

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

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

Сразу начинают перечислять тест-кейсы, не спросив, что это за модуль и где его границы.

Отвечают только про позитивный сценарий через интерфейс и забывают про интеграции, негатив и безопасность.

Не называют приоритеты. Список из ста проверок без порядка выполнения показывает старательность, но не умение работать в сжатые сроки.