Как распределялось тестирование между фронтом и бэком

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

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

Как отвечать

Опишите свой проект по слоям и назовите, кто за что отвечал. Типичный каркас:

• бэкенд: unit-тесты пишут разработчики, на QA API-тесты: позитивные и негативные сценарии, коды ответов, валидация, права. Инструменты зависят от стека: Postman с Newman в CI, REST Assured на Java, pytest с httpx на Python. Сюда же проверка данных в базе через SQL;
• контракт: схема OpenAPI или контрактные тесты (Pact), чтобы изменение API ловилось до того, как упадёт интерфейс;
• фронтенд: компонентные тесты на Jest или Vitest с Testing Library обычно у разработчиков. На QA сквозные сценарии на Playwright или Cypress, кроссбраузерность, вёрстка на разных разрешениях, иногда визуальная регрессия;
• изоляция: фронт тестируют с замоканным API (MSW, WireMock), чтобы не ждать готовности бэкенда, а бэк проверяют без UI;
• критичные потоки: E2E только для главных путей (регистрация, оплата), остальное опускается на уровень API.

Для локализации бага нужны DevTools, вкладка Network. Если сервер ответил неверно, баг на бэке; если данные верные, а отображение нет, на фронте.

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

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

Тестируют всё через интерфейс. Прогон длинный и хрупкий, а ошибки API, до которых UI не даёт дойти (невалидные данные, чужие права), остаются незамеченными.

Не умеют локализовать дефект и заводят баг «не работает форма» без запроса и ответа. Разработчики тратят время на выяснение, чья это зона.

Приводят круглые проценты вроде «снизили баги на 30%» без способа измерения. Первый же уточняющий вопрос это обнаруживает.