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