Какую тестовую документацию составляешь?

Тестовая документация в работе QA инженера

Тестовая документация — это набор документов, которые описывают подход, стратегию, сценарии и результаты тестирования. Она обеспечивает прозрачность процесса и является источником истины для команды.

1. Тест-план (Test Plan)

Основатель тестовой документации:

• Описание: высокоуровневый документ, который определяет стратегию и объем тестирования
• Кто составляет: QA Lead, Test Manager
• Содержит:
  • Цели тестирования
  • Область тестирования (какие функции покрывать)
  • Используемые типы тестирования (функциональное, регрессионное, нагрузочное и т.д.)
  • Расписание тестирования
  • Требуемые ресурсы
  • Критерии входа и выхода
  • Риски и стратегия их снижения

Пример: "Тест-план для версии 3.0: 2 недели тестирования, 50 часов на функциональное тестирование, критерий выхода — 95% багов с приоритетом high найдено"

2. Тест-сценарии (Test Cases)

Детальные инструкции для выполнения тестов:

• Описание: пошаговые действия для проверки функциональности
• Кто составляет: QA инженер
• Содержит:
  • Уникальный ID (TC-001, TC-002)
  • Название сценария
  • Предусловия (какие данные/состояние нужны)
  • Шаги тестирования (нумерованные действия)
  • Ожидаемый результат
  • Фактический результат (заполняется после выполнения)
  • Статус (Passed, Failed, Blocked)
  • Приоритет
  • Тип (функциональный, регрессионный, граничный и т.д.)

Пример:

TC-005: Создание нового пользователя
Предусловия: Пользователь на странице регистрации
Шаги:
1. Ввести email: test@example.com
2. Ввести пароль: Test123!
3. Нажать кнопку "Создать аккаунт"
Ожидаемый результат: Аккаунт создан, пользователь перенаправлен на главную
Фактический результат: [Заполняется после тестирования]
Статус: Passed

3. Чек-листы тестирования (Test Checklists)

Упрощенная версия тест-сценариев:

• Описание: список функций/проверок без детальных пошаговых инструкций
• Когда используется: при быстром тестировании, smoke-тестировании, регрессионном тестировании
• Содержит:
  • Список проверяемых функций
  • Статус выполнения (да/нет/н/п)
  • Комментарии при наличии проблем

Пример:

Смок-тест версии 2.1
☑ Приложение запускается
☑ Авторизация работает
☑ Главная страница загружается
☑ Поиск функционирует
☐ (Баг) Фильтры не отображаются

4. Отчет об ошибках (Bug Report)

Документация найденных дефектов:

• Описание: детальное описание найденной проблемы
• Кто составляет: QA инженер
• Содержит:
  • Заголовок ошибки
  • Описание проблемы
  • Шаги воспроизведения
  • Ожидаемое поведение
  • Фактическое поведение
  • Скриншоты/видео
  • Окружение (ОС, браузер, версия приложения)
  • Приоритет (Critical, High, Medium, Low)
  • Серьезность (Severity)

Пример:

Title: Кнопка "Удалить" недоступна для администратора
Описание: При попытке удалить пользователя администратор не может нажать кнопку
Шаги:
1. Залогиниться как администратор
2. Перейти в управление пользователями
3. Выбрать пользователя
4. Попытаться нажать кнопку "Удалить"
Ожидаемое: Кнопка активна, пользователь удаляется
Фактическое: Кнопка неактивна (серого цвета), клик не срабатывает
Окружение: Chrome 120, Ubuntu 22.04, v2.5.1
Приоритет: High

5. Тест-отчет (Test Report)

Итоговый документ по результатам тестирования:

• Описание: сводка по выполненному тестированию
• Когда создается: после завершения тестирования (для спринта, версии, релиза)
• Содержит:
  • Объем тестирования
  • Процент выполненных тест-сценариев
  • Количество найденных багов (по приоритетам)
  • Статистика: Passed, Failed, Blocked, Skipped
  • Выводы и рекомендации
  • Готовность к релизу

Пример:

Тест-отчет для версии 3.0
Всего тест-сценариев: 120
Выполнено: 118 (98%)
Passed: 110 (93%)
Failed: 8 (7%)

Найдено багов:
- Critical: 1 (невозможно залогиниться)
- High: 3 (ошибки при загрузке данных)
- Medium: 4
- Low: 2

Вывод: Версия НЕ готова к релизу. Необходимо исправить critical баг и провести регрессионное тестирование.

6. Матрица требований (Requirements Traceability Matrix - RTM)

Взаимосвязь требований и тест-сценариев:

• Описание: документ, который показывает, какие тест-сценарии покрывают какие требования
• Содержит:
  • ID требования
  • Описание требования
  • ID связанных тест-сценариев
  • Статус покрытия

Пример:

REQ-101: Пользователь должен иметь возможность отфильтровать заказы по дате
Покрывающие тест-сценарии: TC-045, TC-046, TC-047
Статус: Полностью покрыто

7. Автоматизированные тесты (Test Scripts)

Код для автоматизированного тестирования:

• Инструменты: Selenium, Cypress, PlayWright, Postman, JMeter
• Содержит:
  • Автоматизированные сценарии
  • Ассерты (проверки ожиданий)
  • Логирование результатов

8. Документ по управлению тестовыми данными (Test Data Management)

Описание подготовки данных для тестирования:

• Какие данные использовать
• Как их создавать
• Как очищать после тестирования
• Конфиденциальные данные и их обработка

Инструменты для документации

• Jira — управление задачами, отслеживание багов
• TestRail — управление тест-сценариями и отчетами
• Confluence — тест-планы и документация
• Qase.io — управление тестами и отчеты
• Allure — автоматизированные отчеты
• Google Docs / Spreadsheets — простые чек-листы

Практический процесс документирования

1. На старте версии: составляю тест-план
2. Перед тестированием: пишу тест-сценарии или чек-листы
3. Во время тестирования: заполняю результаты и создаю баг-репорты
4. После тестирования: формирую тест-отчет
5. Для последующих версий: обновляю документацию и переиспользую сценарии

Ключевые правила документирования

• Ясность: тест-сценарий должен быть понятен любому члену команды
• Полнота: описывай предусловия, шаги и ожидания полностью
• Актуальность: обновляй документацию вместе с изменением функциональности
• Воспроизводимость: другой тестировщик должен выполнить тот же сценарий с тем же результатом
• Трассируемость: каждый сценарий должен быть связан с требованием

Заключение

Тестовая документация — это основа профессионального тестирования. Она обеспечивает качество, прозрачность и возможность переиспользования тестов. В современной разработке документация часто интегрирована в системы управления (Jira, TestRail) и автоматизирована.