Как происходило тестирование
Что проверяют
Интервьюер хочет увидеть реальный процесс на вашем прошлом проекте и понять, какое место в нём занимали именно вы. Следом обычно спрашивают, как вы решали, что протестировано достаточно для релиза, и что бы вы поменяли в том процессе.
Как отвечать
Рассказывайте по ходу жизни задачи, от требований до релиза, и на каждом шаге называйте инструмент и свою роль:
- контекст: продукт, размер команды, сколько тестировщиков, как часто релизы, Scrum или Kanban;
- вход в задачу: подключались ли вы на этапе требований, задавали ли вопросы аналитику до начала разработки;
- тест-дизайн: чек-листы или тест-кейсы, где они хранились (TestRail, Qase, Allure TestOps), какие техники применяли: классы эквивалентности, граничные значения;
- виды проверок: смоук после сборки, функциональное тестирование фичи, API через Postman, регресс перед релизом и сколько он занимал;
- автоматизация: была ли, кто писал, на чём (Playwright, Selenium, pytest, REST Assured), запускалась ли в CI и что делали с упавшими тестами;
- баги: трекер (Jira, YouTrack), как разводили severity и priority, кто решал, блокирует ли баг релиз;
- окружения: dev, stage, откуда брали тестовые данные.
Цифры нужны свои: длина регресса в часах, число кейсов, сколько багов доходило до прода. Не придумывайте проценты, их легко проверить уточняющим вопросом. Если процесс был хаотичным, так и скажите и покажите, что вы сделали или предложили: завели чек-лист регресса, договорились о критериях готовности. Это звучит сильнее идеальной картинки из учебника.
Где спотыкаются
Пересказывают теорию: «тестирование бывает функциональное и нефункциональное». Вопрос про ваш проект, общие определения тут не засчитываются.
Говорят только «мы» и не отделяют свою работу от работы команды. Интервьюер так и не понимает, что умеете лично вы.
Не могут ответить на простые уточнения: сколько шёл регресс, кто принимал решение о релизе, что происходило с багом, найденным в проде. Это выдаёт выдуманный или чужой опыт.