Были ли у вас новые фичи в проекте
Что проверяют
Как вы работаете с фичей от требований до релиза и когда подключаетесь: на готовой сборке или ещё на обсуждении задачи. Следом обычно просят рассказать, какие дефекты вы нашли и что из проверок потом автоматизировали.
Как отвечать
Выберите одну фичу, которую вы тестировали сами, и пройдите по этапам, называя свои действия:
- требования: участие в груминге, вопросы аналитику, найденные противоречия и недостающие сценарии до начала разработки;
- тест-дизайн: классы эквивалентности, граничные значения, таблицы решений или диаграмма состояний, если у фичи есть статусы;
- артефакты: чек-лист или тест-кейсы в вашей TMS (Test IT, Qase, Allure TestOps, Zephyr), тестовые данные, доступы на стенде;
- проверка: функциональная, API через Postman или Swagger, интеграции с соседними сервисами, базовая проверка производительности, если фича тяжёлая;
- регресс и релиз: что затронуто в старом функционале, прогон регресса, проверка за фиче-флагом, смоук после выкладки;
- автоматизация: какие сценарии ушли в автотесты и на чём они написаны.
Цифры нужны свои и про вашу работу: сколько дефектов нашли до релиза, сколько из них в требованиях, сколько проскочило в прод и почему. Прирост пользователей после релиза это результат продукта, а не тестирования, и ставить его себе в заслугу рискованно.
Если вы джун и фичу целиком не вели, так и скажите: расскажите про часть, которую проверяли, или про учебный проект. Честное «я отвечал за оплату картой, вот что я там нашёл» звучит лучше общей истории про весь продукт.
Где спотыкаются
Пересказывают, что делает фича и какую пользу принесла бизнесу, а свой вклад описывают одной фразой «протестировал».
Не называют ни одной техники тест-дизайна. Без них непонятно, почему проверок было именно столько и чем выбраны данные.
Забывают про влияние на существующий функционал и про то, что было после релиза. Фраза «покрыли всё на 100%» вызывает у интервьюера только новые вопросы.