Приходилось ли писать тест-план самостоятельно?
Что проверяют
Отличаете ли вы тест-план от набора тест-кейсов. План это договорённость про объём, риски, сроки и критерии, а не список шагов проверки. По ответу видно, участвовали ли вы в планировании или получали задачи готовыми.
Как отвечать
Скажите, какого масштаба документ писали и для чего, а дальше покажите структуру своими словами:
- объект и версии: что тестируем и что явно вне объёма;
- риски и приоритеты: где отказ дороже всего, туда и глубина проверок;
- уровни и виды: дымовые, функциональные, интеграционные, регресс, нагрузка, безопасность;
- окружения, доступы, тестовые данные, заглушки внешних систем;
- критерии входа и выхода: при каком состоянии сборки начинаем и с каким набором дефектов выпускаем;
- роли, сроки, отчётность, что уходит в автоматизацию.
Сильный ход: сказать, что критерии выхода согласуются заранее, а не в ночь перед релизом, и что для небольшой фичи вместо плана хватает страницы стратегии или чек-листа. Ещё лучше назвать риск, который план поймал: несовместимая версия внешнего сервиса, нехватка тестовых данных, стенд без доступа к платёжной песочнице.
Где спотыкаются
Пересказывают оглавление стандарта наизусть, но не могут назвать ни одного риска своего продукта. Проверяют мышление про качество, а не память на названия разделов.
Второе: путают уровни документов. Тест-план, тест-стратегия, чек-лист, тест-кейс и отчёт о тестировании решают разные задачи, а кандидат складывает в план сами кейсы и получает документ, который никто не читает.
Третье: приправляют историю выдуманным процентом снижения дефектов и названием компании из шаблона. Честнее метрика, которую сможете объяснить: сколько дефектов ловили до релиза против найденных после и сколько времени занимал полный регресс.