Как тестировать фичу без требований, если фронтендер утверждает, что фильтры работают?
Что проверяют
Две вещи сразу: умеете ли вы находить ожидаемое поведение, когда его никто не записал, и как ведёте себя, когда разработчик говорит «у меня работает». Интервьюер слушает и технику, и тон. Следом спрашивают: «А если нашли расхождение, это баг или нет?»
Как отвечать
Отсутствие требований не значит отсутствие ожиданий. Источники неявных требований в тестировании называют оракулами, для них есть мнемоника HICCUPPS:
- сам продукт: как ведут себя другие фильтры в этом приложении, прошлая версия, макеты в Figma, задача в трекере и обсуждение в ней;
- контракт API: Swagger или OpenAPI, какие параметры бэкенд вообще принимает;
- аналоги: как фильтры устроены в сопоставимых продуктах и чего пользователь ждёт по привычке;
- люди: владелец продукта или аналитик. Созвон на десять минут экономит день догадок.
Дальше исследовательское тестирование с чартером и ограничением по времени: «исследовать комбинации фильтров в каталоге, чтобы найти неверную выдачу». Откройте DevTools, вкладку Network: уходят ли параметры на сервер или фильтрация идёт на клиенте по уже загруженной первой странице. Сверьте выдачу с API или базой, проверьте сброс, пустой результат, фильтр в URL, сочетание с сортировкой и пагинацией.
С разработчиком говорите фактами. Спросите, какие сценарии он проверял: это даст контекст и покажет, где дыры. Расхождения оформляйте с шагами и ожидаемым поведением со ссылкой на источник ожидания. Если источника нет, это вопрос к продукту, а не баг.
В конце зафиксируйте принятые допущения в задаче, чтобы они стали требованиями для следующей итерации.
Где спотыкаются
Принимают «у меня работает» за результат тестирования. Слова разработчика это гипотеза, а не проверка.
Уходят в конфликт: заводят баги на всё, что не понравилось, без опоры на ожидания.
Тестируют только интерфейс. Фильтр, работающий на клиенте по первой странице, выглядит исправным, пока данных мало.