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