Какие задачи выполняли: фронтендовые или бэкендовые?
Что проверяют
На каком уровне системы вы реально работали и насколько глубоко: только интерфейс или ещё API, база, логи. Интервьюер сверяет ваш профиль с тем, что нужно команде. Почти всегда следом идёт практический вопрос: «Как понять, где баг: на фронте или на бэке?»
Как отвечать
Скажите честно, какая доля была у каждого направления, и назовите инструменты и типичные задачи:
- фронтенд: проверка вёрстки и адаптивности, кроссбраузерность, валидация форм, состояния загрузки и ошибок, доступность; автотесты на Playwright, Cypress или Selenium;
- DevTools и прокси: вкладки Network и Console, подмена ответов через Charles, Fiddler или mitmproxy, чтобы проверить, как интерфейс переживает ошибку 500 или пустой список;
- бэкенд: тестирование REST или gRPC API через Postman или curl, проверка кодов ответа, схемы по OpenAPI, авторизации и прав доступа;
- данные: SQL-запросы, чтобы убедиться, что запись действительно появилась в базе, проверка сообщений в очереди вроде Kafka;
- логи и метрики: поиск ошибки по идентификатору запроса в Kibana или Grafana;
- автоматизация и нагрузка: pytest с requests или REST Assured для API, JMeter или k6 для нагрузки.
Обязательно покажите умение локализовать дефект. Открываете Network: если запрос не ушёл или ушёл с неверными параметрами, проблема на клиенте; если сервер вернул ошибку или неправильные данные, это бэкенд; если ответ верный, а отображение нет, снова фронтенд. Примеры и цифры приводите свои. Если опыт только в UI, так и скажите и расскажите, как вы уже начали разбираться с API.
Где спотыкаются
Под фронтендом понимают только «прокликать сценарий». Без DevTools и понимания запросов такой опыт звучит поверхностно.
Не могут объяснить, как отличают баг клиента от бага сервера, и заводят дефект «не работает кнопка» на всех сразу.
Приводят результаты, которые тестировщик не измеряет, например «удовлетворённость клиентов выросла на 20%». Лучше говорить о найденных дефектах, покрытии и времени прогона.