Как ставятся задачи на тестирование
Что проверяют
Как в вашей команде был устроен путь задачи от разработки до проверки и какую часть тестирования вы брали на себя как Java-разработчик. Следом спрашивают, какие тесты вы пишете сами, что отдаёте QA и что считается готовой задачей.
Как отвечать
Опишите процесс, в котором работали, по шагам:
- критерии приёмки: у задачи в Jira или YouTrack есть проверяемые условия, часто в виде Given/When/Then. По ним QA готовит тест-кейсы, а вы понимаете, что именно реализовать;
- Definition of Done: что входит в «готово» до передачи на тестирование. Обычно это юнит-тесты, зелёный CI, пройденное код-ревью, обновлённая спецификация API;
- что тестирует разработчик: юнит-тесты на JUnit 5 с Mockito и AssertJ, интеграционные через
@SpringBootTestили срезы вроде@WebMvcTestи@DataJpaTest, настоящие база и брокер в Testcontainers. Порог покрытия, если он есть, проверяет JaCoCo в CI; - передача в QA: задача уходит в статус тестирования с указанием стенда, версии сборки и затронутых мест. Хорошая практика: разработчик сам пишет, где возможны регрессии;
- дефекты: найденный баг либо заводится отдельной задачей, либо возвращает исходную в работу. Это разные договорённости, и стоит знать, какая была у вас.
Можно упомянуть сдвиг тестирования влево: QA подключается уже на обсуждении требований, а автотесты пишутся параллельно с кодом.
Если этот вопрос задаёте вы работодателю, из ответа видно главное: есть ли в команде QA, кто пишет автотесты, сколько длится регресс перед релизом и не окажетесь ли вы единственным, кто что-то проверяет.
Где спотыкаются
Говорят «тестированием занимается QA», будто разработчик за качество не отвечает. Для Java-разработчика это минус: юнит- и интеграционные тесты от вас ждут по умолчанию.
Пересказывают учебник про тест-план и анализ рисков, не описав, как это выглядело в команде. Нужна конкретика: статусы, стенды, кто и когда двигает задачу.
Путают критерии приёмки и Definition of Done. Первые относятся к конкретной задаче, второй действует для любой задачи команды.