Был ли опыт работы с фронтендом
Что проверяют
Насколько глубоко вы понимаете то, что тестируете: можете ли локализовать дефект до фронтенда или бэкенда и читать то, что происходит в браузере. Автоматизатора следом спросят про локаторы и нестабильные тесты, ручного тестировщика про DevTools и кроссбраузерность.
Как отвечать
Это вопрос про опыт, поэтому начните с проекта: что за продукт, обычный сайт или SPA, что вы в нём проверяли. Затем покажите, какими знаниями пользовались:
- DevTools: вкладка Network для запросов, статус-кодов и тела ответа, Console для ошибок JS, Application для cookies и
localStorage, эмуляция устройств для адаптивной вёрстки; - локализация бага: если API вернул правильные данные, а на экране не то, дефект на фронтенде; если ответ уже кривой, баг заводится на бэкенд с приложенным запросом;
- кроссбраузерность: Chrome, Firefox и Safari на WebKit, причём в Safari чаще всего вылезают отличия в вёрстке и работе с датами;
- доступность: проверка через Lighthouse или axe, навигация с клавиатуры, подписи у полей;
- автотесты: Playwright, Cypress или Selenium WebDriver. Хорошо упомянуть локаторы по роли и
data-testidвместо хрупких XPath и автоожидание в Playwright, которое снимает большую часть нестабильности.
Если писали код, честно назовите уровень: читали вёрстку и JS, чинили селекторы, писали тесты на TypeScript. Если работали только руками, так и говорите, и покажите, что понимаете основы: как браузер получает страницу, чем SPA отличается от серверного рендеринга, почему после клика данные подгружаются не сразу. Цифры, вроде доли багов, найденных до релиза, приводите только свои и реальные.
Где спотыкаются
Перечисляют инструменты без примера: «знаю Selenium и Cypress». Интервьюер тут же попросит описать один тест, и ответ рассыпается.
Заводят баг на фронтенд, не посмотрев ответ сервера во вкладке Network. Для команды это лишний круг между разработчиками.
Отвечают коротким «нет», если фронтенд-разработкой не занимались. Вопрос обычно про тестирование интерфейсов, и такой опыт почти у всех есть.