Были ли показы заказчику или запасникам
Что проверяют
Выходит ли ваша работа за пределы багтрекера: участвовали ли вы в демо, приёмке, общении с заказчиком и другими заинтересованными лицами. Под «запасниками» в этой формулировке, судя по всему, имеются в виду как раз они, так и отвечайте. Следом обычно спрашивают, что вы делали, если на показе всплыл баг.
Как отвечать
Покажите, какую роль в показе играет QA. Каркас на своём опыте:
- формат: демо на спринт-ревью, приёмочное тестирование вместе с заказчиком (UAT), показ промежуточной версии бизнесу, показ перед релизом;
- подготовка: проверили сборку на том стенде, где будет показ, прогнали смоук по сценариям демо, заранее подготовили тестовые данные и учётные записи, чтобы не создавать их на глазах у заказчика, составили список известных ограничений;
- роль на показе: вели сценарий или страховали того, кто показывает, фиксировали замечания, сразу отделяли баги от новых пожеланий;
- после показа: завели задачи в Jira, разметили, что баг, а что изменение требований, дополнили тест-кейсы в TestRail или Allure TestOps сценариями, которые заказчик проверял сам.
Нужны свои примеры и цифры: сколько было показов, сколько замечаний пришло, что из них ушло в регресс. Хорошо звучит история, где показ выявил расхождение в понимании требований, а вы потом добавили проверку этого сценария.
Если на показах вы не бывали, так и скажите: демо проводил тимлид или аналитик. Опишите, как вы готовили к нему стенд и данные, и что хотели бы участвовать сами. Это честно и всё равно показывает понимание процесса.
Где спотыкаются
Описывают показ как презентацию слайдов. Заказчик приходит смотреть работающий продукт, и задача QA в том, чтобы он работал.
Не готовят данные и стенд, и демо ломается на регистрации или на пустом списке. Это самый частый провал, и интервьюер ждёт рассказа о том, как вы его предотвращали.
Спорят с заказчиком на встрече: «это не баг, это по ТЗ». Правильнее зафиксировать замечание и разобрать его с аналитиком после показа.