Зачем нужны стандарты документации тестирования?
При смене работы вы сталкиваетесь с новыми тест-планами, новыми форматами отчётов, новыми способами организации тест-кейсов. Каждая организация будто заново изобретает документацию. IEEE 829 существует, чтобы решить эту проблему, предоставляя стандартизированный фреймворк.
Что такое IEEE 829?
IEEE 829 (официально «IEEE Standard for Software and System Test Documentation») определяет набор документов, охватывающих весь процесс тестирования. Впервые опубликован в 1998 году, обновлён в 2008 — остаётся наиболее цитируемым стандартом документации тестирования.
Стандарт определяет восемь основных типов документов в трёх группах:
Восемь типов документов
1. Test Plan (Тест-план)
Назначение: Главный документ, описывающий весь объём тестирования — область, подход, ресурсы, график и ответственные.
Ключевые разделы: Идентификатор, введение, объекты тестирования, что тестируется / что не тестируется, подход, критерии прохождения/провала, критерии приостановки/возобновления, результаты тестирования, задачи и график, требования к окружению, ответственные, риски и контингенции, утверждения.
В современной практике: Тест-план остаётся самым используемым документом. В Agile это может быть облегчённый документ, обновляемый каждый спринт.
2. Test Design Specification (Спецификация дизайна тестов)
Назначение: Описывает детальный подход к тестированию конкретной функции. Связующее звено между тест-планом и конкретными тест-кейсами.
Пример: Для функции входа: «Тестировать с помощью equivalence partitioning для поля имени пользователя и boundary value analysis для поля пароля.»
3. Test Case Specification (Спецификация тест-кейсов)
Назначение: Документирует отдельные тест-кейсы с достаточной детализацией для выполнения.
Пример:
| Поле | Содержание |
|---|---|
| ID | TC-LOGIN-003 |
| Описание | Вход с валидным email и паролем минимальной длины |
| Предусловия | Аккаунт существует с паролем «Pass1234» (8 символов) |
| Ввод | Email: user@test.com, Password: Pass1234 |
| Ожидаемый результат | Пользователь перенаправлен на дашборд, сессия создана |
4. Test Procedure Specification (Спецификация тестовых процедур)
Назначение: Пошаговая процедура выполнения одного или нескольких тест-кейсов.
В современной практике: Реже создаётся как отдельный документ. Большинство команд включают шаги в сам тест-кейс или полагаются на автоматизированные скрипты.
5. Test Log (Журнал тестирования)
Назначение: Хронологическая запись активностей и результатов тестирования.
В современной практике: Инструменты управления тестами (TestRail, Xray, Zephyr) автоматически генерируют журналы. Ручные журналы встречаются редко за пределами регулируемых отраслей.
6. Test Incident Report (Отчёт об инциденте)
Назначение: Документирует любое событие, требующее расследования — обычно сбой теста. По сути это баг-репорт в современных терминах.
В современной практике: Напрямую соответствует баг-репортам в Jira, GitHub Issues или Azure DevOps.
7. Test Item Transmittal Report (Отчёт о передаче тестового объекта)
Назначение: Документирует передачу тестовых объектов (билдов, конфигураций) от разработки к тестированию.
В современной практике: В основном заменён CI/CD-пайплайнами и заметками о деплое.
8. Test Summary Report (Итоговый отчёт о тестировании)
Назначение: Подводит итог тестирования в конце фазы или проекта. Предоставляет данные для решений о релизе.
Это один из самых критичных документов, так как он напрямую влияет на решение go/no-go о релизе.
Когда использовать IEEE 829
Полное соответствие уместно
- Регулируемые отрасли (здравоохранение, авиация, финансы, оборона)
- Государственные контракты
- Системы критической безопасности
- Крупные проекты с несколькими командами тестирования
Облегчённый подход лучше
- Agile/Scrum-команды
- Стартапы, создающие MVP
- Внутренние инструменты
- Проекты с зрелыми инструментами управления тестами
Практический компромисс
- Всегда создавать: Тест-план, Итоговый отчёт
- Создавать по необходимости: Спецификации тест-кейсов, Отчёты об инцидентах
- Часто автоматизировано: Журналы тестирования, Процедуры (инструментами)
- Редко нужно: Спецификации дизайна тестов, Отчёты о передаче (кроме регулируемых отраслей)
IEEE 829 в программе ISTQB
IEEE 829 упоминается в программе ISTQB Foundation Level. Для сертификации нужно знать восемь типов документов, их назначение и когда формальная документация уместна.
Упражнение: сопоставьте IEEE 829 с вашим проектом
Сценарий: Вы QA Lead в e-commerce компании. Команда использует Jira, TestRail и GitHub Actions. Работаете по Scrum с двухнедельными спринтами.
Текущая документация:
- Документ стратегии тестирования (обновляется ежегодно)
- Тест-кейсы в TestRail (по фичам)
- Баг-репорты в Jira
- Отчёты о тестировании за спринт (автоматические из TestRail)
- Release notes в GitHub
Задания:
- Сопоставьте каждый текущий документ с типом IEEE 829
- Определите, какие документы IEEE 829 отсутствуют — для каждого решите: (a) нужно добавить, (b) покрыто инструментами, (c) не нужно
- Если компании нужно соответствовать PCI-DSS для нового платёжного функционала, какие дополнительные документы IEEE 829 потребуется формализовать?
Подсказка
Перечислите все 8 документов IEEE 829 и посмотрите, какие из текущих документов соответствуют каждому. Помните, что современные инструменты часто объединяют несколько типов. Для PCI-DSS подумайте, что нужно видеть аудиторам.
Решение
1. Сопоставление
| Текущий документ | Эквивалент IEEE 829 |
|---|---|
| Стратегия тестирования | Тест-план (частично) |
| Тест-кейсы в TestRail | Спецификация тест-кейсов |
| Баг-репорты в Jira | Отчёт об инциденте |
| Спринтовые отчёты | Итоговый отчёт (частично) |
| Release notes | Отчёт о передаче (частично) |
2. Недостающие документы
| Документ IEEE 829 | Статус | Решение |
|---|---|---|
| Тест-план | Частично | (a) Добавить планы на уровне спринта |
| Спецификация дизайна | Отсутствует | (c) Не нужно — TestRail организует по фичам |
| Спецификация тест-кейсов | Покрыто | (b) Покрыто инструментами |
| Спецификация процедур | Отсутствует | (b) Покрыто — шаги в тест-кейсах |
| Журнал тестирования | Отсутствует формально | (b) Покрыто — TestRail генерирует автоматически |
| Отчёт об инциденте | Покрыто | (b) Покрыто Jira |
| Отчёт о передаче | Частично | (c) Не нужно — CI/CD-пайплайн |
| Итоговый отчёт | Частично | (a) Добавить полные отчёты на уровне релиза |
3. Дополнительные документы для PCI-DSS
- Тест-план — формальный, подписанный, специально для платёжного модуля
- Журнал тестирования — формальный, с временными метками и идентификацией тестировщиков
- Итоговый отчёт — комплексный, с результатами security testing
- Отчёты об инцидентах — для всех дефектов безопасности с формальной документацией
- RTM — трассировка между требованиями PCI-DSS и тест-кейсами
Ключевые выводы
- IEEE 829 определяет 8 стандартизированных документов: планирование, спецификация и отчётность
- Тест-план и итоговый отчёт — наиболее универсально применимые документы
- Современные инструменты автоматизируют многое из того, что определяет IEEE 829
- Полное соответствие наиболее важно в регулируемых отраслях
- Большинство команд выигрывают от гибридного подхода
- Стандарт обеспечивает общий словарь для документации тестирования между организациями