Введение в IEEE 829
IEEE 829, формально известный как «Standard for Software and System Test Documentation», предоставляет стандартизированный формат для документации тестирования. Впервые опубликованный в 1998 году и обновлённый в 2008, он определяет шаблоны для тест-планов, тест-дизайнов, тест-кейсов, тест-процедур и тест-отчётов.
Хотя многие команды сегодня используют agile-подходы с лёгкой документацией, IEEE 829 остаётся эталонным стандартом для понимания, что должен содержать полный тест-план. Даже если вы никогда не напишете полный документ IEEE 829, знание его структуры делает вас лучше в создании тест-планов любого формата.
Разделы тест-плана IEEE 829
1. Идентификатор тест-плана
Уникальный идентификатор документа, обычно включающий название проекта, версию и дату.
Пример: TP-ProjectAlpha-v2.1-2026-03
2. Введение
Краткий обзор проекта, тестируемой системы и цели этого тест-плана. Включает ссылки на связанные документы.
3. Объекты тестирования
Список конкретных программных объектов (модулей, функций, компонентов), подлежащих тестированию, с номерами версий.
- Модуль аутентификации пользователей v3.2.1
- Сервис обработки платежей v1.4.0
- Движок уведомлений v2.0.0
- REST API Gateway v5.1.2
4. Тестируемые функции
Перечислите, какие функции будут тестироваться и какие характеристики качества применяются.
| Функция | Функциональное | Производительность | Безопасность | Юзабилити |
|---|---|---|---|---|
| Вход пользователя | Да | Да | Да | Да |
| Сброс пароля | Да | Нет | Да | Да |
| Оформление заказа | Да | Да | Да | Да |
| Загрузка дашборда | Да | Да | Нет | Да |
| Email-уведомления | Да | Нет | Нет | Нет |
5. Функции, не подлежащие тестированию
Явно укажите, какие функции исключены из тестирования и почему.
- Скрипты миграции БД — обрабатываются командой DBA с отдельной валидацией
- SDK аналитики третьей стороны — тестируется вендором, мы тестируем только точку интеграции
- Устаревший модуль отчётов — запланирован к выводу из эксплуатации в Q2
Этот раздел критичен. Неуказанные исключения приводят к взаимным обвинениям, когда баги проскальзывают.
6. Подход
Опишите общий подход к тестированию для каждого объекта или группы функций.
Подход функционального тестирования:
- Выведение тест-кейсов из требований с использованием эквивалентного разбиения и анализа граничных значений
- Автоматизация регрессионного набора, покрывающего все критические пути
- Ручное исследовательское тестирование для новых фич каждый спринт
Подход тестирования производительности:
- Базовый нагрузочный тест на 5,000 одновременных пользователей
- Стресс-тест до 20,000 пользователей
- Тест на выносливость 48 часов при нормальной нагрузке
7. Критерии прохождения/непрохождения
Определите, что считается прохождением или непрохождением для каждого объекта тестирования.
- Unit-тесты: 100% прохождение, минимум 80% покрытия кода
- Интеграционные тесты: 100% прохождение критических путей, 95% общее
- Системные тесты: Ноль критических/высоких багов, менее 5 средних
- Тесты производительности: P95 время отклика < 2 секунд, частота ошибок < 0.1%
8. Критерии приостановки и возобновления
Критерии приостановки — когда остановить тестирование:
- Более 20% тест-кейсов заблокированы одним дефектом
- Тестовое окружение нестабильно (более 3 незапланированных падений в день)
- Критический дефект билда, блокирующий основную функциональность
Критерии возобновления — когда продолжить:
- Блокирующий дефект исправлен и верифицирован
- Стабильность окружения подтверждена в течение 4 часов
- Новый билд с исправлением развёрнут и верифицирован
9. Поставляемые документы
Список всех документов и артефактов, создаваемых в процессе тестирования.
10. Тестовое окружение
Требования к оборудованию, ПО, сети и инструментам.
11. Ответственности
| Роль | Человек | Обязанности |
|---|---|---|
| Тест-менеджер | Jane Smith | Утверждение плана, распределение ресурсов |
| QA Lead | John Doe | Дизайн тестов, ежедневная координация |
| QA Engineer | Alice Brown | Выполнение тестов, репортинг багов |
| DevOps | Bob Wilson | Настройка окружения, CI/CD pipeline |
12. Расписание
Определите вехи, фазы и дедлайны для каждой активности тестирования.
13. Риски и планы действий
Определите риски, специфичные для данного тестирования, с планами снижения.
14. Утверждения
Раздел sign-off для стейкхолдеров, которые должны утвердить тест-план перед началом выполнения.
Упражнение: Напишите тест-план по IEEE 829
Создайте тест-план для приложения интернет-банкинга. Система включает: управление счетами, переводы средств (внутренние и международные), оплата счетов, просмотр инвестиционного портфеля и мобильное внесение чеков.
Напишите все 14 разделов, адаптируя глубину к сложности каждой функции.
Подсказка
Приоритизируйте тестирование безопасности для всех финансовых транзакций. Международные переводы имеют требования регуляторного соответствия. Мобильное внесение чеков включает обработку изображений и OCR — граничные случаи включают размытые изображения, сложенные чеки и нестандартные форматы.Решение
1. Идентификатор: TP-OnlineBanking-v1.0-2026-03
2. Введение: Тест-план для SecureBank Online Banking Platform v4.0, покрывающий веб и мобильные интерфейсы для розничных клиентов.
3. Объекты тестирования: Account Service v4.0, Transfer Service v3.2, Bill Pay Service v2.1, Investment View v1.5, Mobile Deposit v1.0
4. Тестируемые функции: Все пять модулей — функциональное, производительность, безопасность, юзабилити, доступность
5. Не тестируется: Внутренняя сверка back-office (отдельная команда), интеграция с банкоматами (команда оборудования), внутренности API кредитного скоринга
6. Подход: На основе рисков — переводы и платежи = критический (100% автоматизация + скан безопасности), управление счетами = высокий (90% автоматизация), просмотр инвестиций = средний (функциональное + исследовательское), мобильное внесение = высокий (функциональное + edge cases изображений)
7. Прохождение/Непрохождение: Ноль критических багов, ноль уязвимостей OWASP Top 10, P95 < 1.5с для переводов, 100% точность финансовых расчётов
8. Приостановка: Любой баг повреждения данных, любая брешь безопасности, ошибки расчёта сумм переводов
9. Поставляемые документы: Тест-план, 450+ тест-кейсов, ежедневные отчёты, отчёты сканирования безопасности, результаты производительности, итоговый отчёт
10. Окружение: Staging-зеркало production, обезличенные данные клиентов, sandbox платёжного шлюза, mock регуляторных API
11. Ответственности: Тест-менеджер (утверждение, отчётность), QA Lead (дизайн, координация), 3 QA Engineer (выполнение), Security Engineer (тестирование на проникновение), DevOps (окружение)
12. Расписание: Спринт 1-2: Дизайн тестов. Спринт 3-5: Фаза выполнения 1. Спринт 6-7: Фаза 2 + производительность. Спринт 8: Безопасность + UAT.
13. Риски: Изменения регуляторных требований — еженедельный мониторинг. Недоступность платёжного шлюза — mock fallback. Фрагментация мобильных устройств — топ-10 устройств по доле рынка.
14. Утверждения: CTO, Head of Product, Compliance Officer, QA Director
Адаптация IEEE 829 для Agile
В agile вы не пишете тест-план на 50 страниц в начале. Вместо этого:
- Ведите живой тест-план — обновляйте каждый спринт в wiki (Confluence, Notion)
- Объедините разделы 4-5 в простую таблицу области, обновляемую по спринтам
- Замените раздел 12 (расписание) каденцией тестирования по спринтам
- Автоматизируйте раздел 9 — большинство артефактов генерируются CI/CD (отчёты покрытия, результаты выполнения)
- Сфокусируйтесь на разделах 6-8 — подход, критерии прохождения и приостановки наиболее ценны для agile-команд
Дух IEEE 829 — структурированность, прослеживаемость, явность области и критериев — остаётся актуальным независимо от методологии.
Ключевые выводы
- IEEE 829 определяет 14 разделов для полного тест-плана
- Критические разделы: тестируемые/нетестируемые функции, подход, критерии прохождения и приостановки
- Адаптируйте для agile, сохраняя лёгкость, «живость» и фокус на спринтах
- Стандарт даёт структуру для размышления о тестировании — даже если вы не следуете ему буквально
- Всегда указывайте, что НЕ тестируется — это предотвращает обвинения при обнаружении багов в нетестируемых областях