Какой тип документации вы создавали и для кого
Что проверяют
Умеете ли вы писать документы под читателя, а не для галочки, и понимаете ли, сколько документации проекту на самом деле нужно. Следом просят пример: как выглядел ваш баг-репорт или чем тест-план отличался от чек-листа.
Как отвечать
Стройте ответ от аудитории, а не от списка типов из ISTQB. Для каждого документа назовите, кто его читал и какое решение по нему принималось:
- баг-репорты для разработчиков: шаги, ожидаемый и фактический результат, окружение, версия сборки, логи или HAR-файл. Хороший репорт воспроизводится без вопросов к автору;
- чек-листы и тест-кейсы для QA: чек-листы для быстрой проверки в спринте, подробные кейсы для регресса и передачи новичкам. Где вели: TestRail, Qase, Allure TestOps, Zephyr в Jira;
- тест-план или стратегия для менеджера и команды: что тестируем, что сознательно не тестируем, окружения, критерии входа и выхода, риски;
- отчёт о тестировании для продакта: что прошло и упало, открытые дефекты по критичности, рекомендация «выпускать или нет»;
- инструкции для поддержки: как воспроизвести типовую проблему клиента, какие учётки и стенды брать.
Дальше расскажите один конкретный случай: что вы изменили в документации и что это дало. Например, заменили устаревшие тест-кейсы чек-листами и сократили регресс, или ввели шаблон баг-репорта, после которого разработчики перестали возвращать задачи с «не воспроизводится». Цифры берите только свои, придуманные проценты разваливаются на первом уточнении.
Если опыт небольшой, честно назовите то, что писали сами, обычно это баг-репорты и чек-листы, и покажите, что понимаете, зачем нужны остальные документы и кто их читает.
Где спотыкаются
Перечисляют все виды документации подряд, не сказав, для кого писался каждый. Звучит как пересказ учебника.
Гордятся объёмом: «написал 2000 тест-кейсов». Интервьюер тут же думает о поддержке: кто их актуализирует после каждого изменения требований.
Не могут на месте описать структуру своего баг-репорта. Это самый частый документ тестировщика, и путаница между серьёзностью и приоритетом здесь заметна сразу.