Кто занимается тестированием в команде

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

Считаете ли вы качество своей зоной ответственности или отдаёте его тестировщикам. Для Java-разработчика почти всегда следует уточнение: какие тесты вы пишете сами, какими инструментами и что проверяет CI перед мержем.

Как отвечать

Опишите распределение, опираясь на пирамиду тестов:

• разработчик: юнит-тесты на JUnit с Mockito и AssertJ, интеграционные тесты на Testcontainers с настоящими PostgreSQL или Kafka в контейнере вместо H2 и заглушек;
• срезы Spring: @WebMvcTest для контроллеров, @DataJpaTest для репозиториев, @SpringBootTest для полного контекста только там, где он действительно нужен, потому что он медленный;
• контракты между сервисами: Spring Cloud Contract или Pact, чтобы изменение API ловилось до интеграционного стенда;
• QA-инженер: тест-дизайн, исследовательское тестирование, сквозные сценарии, регресс и часто автотесты на уровне API и интерфейса;
• CI: тесты и порог покрытия через JaCoCo блокируют мерж.

Хорошо показать, что QA подключается рано: на обсуждении требований, а не когда фича готова. Тогда тестировщик находит дыры в сценариях до кода, а разработчик пишет тесты, уже зная граничные случаи.

Если отдельного QA не было, скажите об этом и объясните, как команда закрывала пробел: ревью тестов, приёмка продактом, дежурство после релиза. Если было наоборот и тесты писал только QA, честно признайте и назовите, что вы начали делать сами.

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

Отвечают «тестированием занимается QA». Для разработчика это худший вариант: интервьюер слышит, что вы отдаёте код без проверки.

Называют Selenium своим основным инструментом. У Java-разработчика основной объём тестов лежит ниже, в юнит- и интеграционных тестах, а браузерные сценарии обычно ведут автотестировщики.

Гонятся за процентом покрытия. Сто процентов строк при тестах без проверок ничего не гарантируют, важнее покрыть бизнес-правила и граничные случаи.