Кто пишет юнит и UI тесты
Что проверяют
Понимаете ли вы пирамиду тестирования и границы ответственности между разработкой и QA. Интервьюеру важно услышать не «юнит пишут разработчики, остальное мы», а почему так и где эти зоны пересекаются. Следом часто спрашивают, как решить, на каком уровне проверять конкретный кейс.
Как отвечать
Начните с разделения по уровням:
- юнит-тесты: пишут разработчики, в том же репозитории и обычно в той же задаче, что и код. Они проверяют функцию или класс в изоляции, выполняются за миллисекунды и прогоняются в CI на каждый коммит (JUnit, pytest, Jest, XCTest в зависимости от стека);
- компонентные и интеграционные: чаще тоже разработчики, иногда вместе с автоматизаторами, особенно тесты API;
- UI-тесты (end-to-end): обычно QA-автоматизаторы. Инструменты: Playwright, Selenium или Selenide, Cypress, для мобильных Appium, Espresso, XCUITest. Код организуют через Page Object или похожий паттерн.
Затем покажите, что граница подвижна. В командах, где качество считают общей задачей, разработчики пишут и часть UI-тестов, а QA участвует в юнит-уровне по-своему: смотрит на ревью, какие случаи покрыты, предлагает граничные значения и классы эквивалентности.
Объясните и логику пирамиды: юнит-тестов много, они дешёвые и стабильные; UI-тестов мало, потому что они медленные, хрупкие и дорогие в поддержке. Правило расчёта скидки нет смысла проверять через браузер, а сценарий «пользователь оформил заказ» без UI целиком не проверить.
Если вы сами писали автотесты, назовите стек, сколько тестов было в наборе, сколько длился прогон и как вы боролись с нестабильными (flaky) тестами.
Где спотыкаются
Говорят, что юнит-тесты тоже пишет QA. Бывает, но это признак сломанного процесса: тестировщик не видит внутренней логики так, как автор кода.
Предлагают покрыть UI-тестами всё подряд. Получается «перевёрнутая пирамида»: прогон на час и падения из-за таймингов, которым никто не верит.
Путают UI-тесты с ручной проверкой интерфейса. Вопрос про автоматизацию, и отвечать стоит про инструменты и код.