Какие виды тестовой документации существуют и с какими вы работали
Что проверяют
Различаете ли вы документы по назначению и понимаете ли, что не всё нужно в каждом проекте.
Как отвечать
По этапам:
- тест-план: что тестируем, чем, кто, в какие сроки, какие риски, критерии входа и выхода. В небольших командах часто сокращается до раздела в Confluence;
- тест-кейсы: шаги, ожидаемый результат, предусловия. Нужны там, где проверку выполняет не автор и где важна воспроизводимость;
- чек-листы: список того, что проверить, без пошаговых инструкций. Быстрее в поддержке и чаще уместнее кейсов;
- тестовые данные и матрица покрытия: какие требования какими проверками закрыты;
- отчёт о дефекте: шаги, фактический и ожидаемый результат, окружение, логи, видео, приоритет и серьёзность;
- отчёт о тестировании: что прогнали, что нашли, какие риски остались, можно ли выпускать;
- матрица трассируемости: связь требований, кейсов и дефектов. Нужна в регулируемых областях, в обычном продукте избыточна.
Полезно добавить свою позицию: документация нужна ровно настолько, насколько её читают. Сто кейсов, которые никто не открывает, хуже одного живого чек-листа. Поэтому подробные кейсы пишутся на критичный путь и на сложную предметную логику, остальное чек-листами.
> «Работаю с чек-листами и кейсами в TestRail, дефекты в Jira по обязательному шаблону, перед релизом собираю короткий отчёт: что прогнали, что нашли, какие риски остались».
Где спотыкаются
Считают, что тест-план нужен всегда и в полном объёме.
Путают серьёзность и приоритет дефекта.
Пишут кейсы без предусловий и ожидаемого результата.
Заводят документацию ради процесса, а не ради пользы, и она устаревает за месяц.