Introduction to IEEE 829
IEEE 829, formally known as the “Standard for Software and System Test Documentation,” provides a standardized format for test documentation. Originally published in 1998 and updated in 2008, it defines templates for test plans, test designs, test cases, test procedures, and test reports.
While many teams today use agile approaches that favor lightweight documentation, IEEE 829 remains the gold standard for understanding what a comprehensive test plan should contain. Even if you never write a full IEEE 829 document, knowing its structure makes you better at creating test plans of any format.
IEEE 829 Test Plan Sections
1. Test Plan Identifier
A unique identifier for the document, typically including project name, version, and date.
Example: TP-ProjectAlpha-v2.1-2026-03
This identifier is used for traceability — linking test results back to the specific plan that defined them.
2. Introduction
A brief overview of the project, the system under test, and the purpose of this test plan. Include references to related documents (requirements specification, design documents, test strategy).
3. Test Items
List the specific software items (modules, features, components) being tested, including version numbers.
- User Authentication Module v3.2.1
- Payment Processing Service v1.4.0
- Notification Engine v2.0.0
- REST API Gateway v5.1.2
4. Features to Be Tested
Enumerate which features will be tested and which quality characteristics apply.
| Feature | Functional | Performance | Security | Usability |
|---|---|---|---|---|
| User login | Yes | Yes | Yes | Yes |
| Password reset | Yes | No | Yes | Yes |
| Payment checkout | Yes | Yes | Yes | Yes |
| Dashboard loading | Yes | Yes | No | Yes |
| Email notifications | Yes | No | No | No |
5. Features Not to Be Tested
Explicitly state which features are excluded from testing and the rationale.
- Admin database migration scripts — handled by DBA team with separate validation
- Third-party analytics SDK — vendor-tested, we test only the integration point
- Legacy reporting module — scheduled for deprecation in Q2, no new development
This section is critical. Unstated exclusions lead to finger-pointing when bugs slip through.
6. Approach
Describe the overall test approach for each test item or feature group.
Functional testing approach:
- Derive test cases from requirements using equivalence partitioning and boundary value analysis
- Automate regression suite covering all critical paths
- Manual exploratory testing for new features each sprint
Performance testing approach:
- Baseline load test at 5,000 concurrent users
- Stress test up to 20,000 users
- Endurance test for 48 hours at normal load
7. Item Pass/Fail Criteria
Define what constitutes pass or fail for each test item.
- Unit tests: 100% pass rate, minimum 80% code coverage
- Integration tests: 100% pass rate for critical paths, 95% overall
- System tests: Zero critical/high bugs, fewer than 5 medium bugs
- Performance tests: P95 response time < 2 seconds, error rate < 0.1%
8. Suspension and Resumption Criteria
Suspension criteria — when to stop testing:
- More than 20% of test cases blocked by the same defect
- Test environment is unstable (more than 3 unplanned outages per day)
- Critical build defect preventing core functionality
Resumption criteria — when to resume:
- Blocking defect resolved and verified
- Environment stability confirmed for 4 consecutive hours
- New build deployed with fix verified
9. Test Deliverables
List all documents and artifacts produced during testing:
- Test plan (this document)
- Test case specifications
- Test execution reports (daily/weekly)
- Defect reports
- Test summary report
- Coverage reports
10. Test Environment
Specify hardware, software, network, and tool requirements.
11. Responsibilities
| Role | Person | Responsibilities |
|---|---|---|
| Test Manager | Jane Smith | Test plan approval, resource allocation, stakeholder reporting |
| QA Lead | John Doe | Test design, daily coordination, defect triage |
| QA Engineer | Alice Brown | Test execution, bug reporting, automation scripts |
| DevOps | Bob Wilson | Environment setup, CI/CD pipeline, monitoring |
12. Schedule
Define milestones, phases, and deadlines for each testing activity.
13. Risks and Contingencies
Identify risks specific to this testing effort with mitigation plans.
14. Approvals
Sign-off section for stakeholders who must approve the test plan before execution begins.
Exercise: Write an IEEE 829 Test Plan
Create a test plan for an online banking application. The system has: account management, fund transfers (domestic and international), bill payments, investment portfolio view, and mobile check deposit.
Write all 14 sections, adapting the depth to the complexity of each feature.
Hint
Prioritize security testing for all financial transactions. International transfers have regulatory compliance requirements. Mobile check deposit involves image processing and OCR — edge cases include blurry images, folded checks, and non-standard check formats.Solution
1. Identifier: TP-OnlineBanking-v1.0-2026-03
2. Introduction: Test plan for SecureBank Online Banking Platform v4.0, covering web and mobile interfaces for personal banking customers.
3. Test Items: Account Service v4.0, Transfer Service v3.2, Bill Pay Service v2.1, Investment View v1.5, Mobile Deposit v1.0
4. Features Tested: All five modules — functional, performance, security, usability, accessibility
5. Not Tested: Internal back-office reconciliation (separate team), ATM integration (hardware team), third-party credit score API internals
6. Approach: Risk-based — transfers and payments = critical (100% automation + security scan), account management = high (90% automation), investment view = medium (functional + exploratory), mobile deposit = high (functional + image edge cases)
7. Pass/Fail: Zero critical bugs, zero security vulnerabilities in OWASP Top 10, P95 < 1.5s for transfers, 100% data accuracy for financial calculations
8. Suspension: Any data corruption bug, any security breach in testing, transfer amount calculation errors
9. Deliverables: Test plan, 450+ test cases, daily execution reports, security scan reports, performance test results, test summary report
10. Environment: Staging mirror of production, anonymized customer data, sandbox payment gateway, mock regulatory APIs
11. Responsibilities: Test Manager (approval, reporting), QA Lead (design, coordination), 3 QA Engineers (execution), Security Engineer (penetration testing), DevOps (environment)
12. Schedule: Sprint 1-2: Test design. Sprint 3-5: Execution phase 1 (core flows). Sprint 6-7: Execution phase 2 (edge cases + performance). Sprint 8: Security testing + UAT.
13. Risks: Regulatory changes during testing — monitor compliance updates weekly. Third-party payment gateway downtime — implement mock fallback. Mobile device fragmentation — test on top 10 devices by market share.
14. Approvals: CTO, Head of Product, Compliance Officer, QA Director
Adapting IEEE 829 for Agile
In agile, you do not write a 50-page test plan upfront. Instead:
- Keep a living test plan — update it each sprint in your wiki (Confluence, Notion)
- Merge sections 4-5 into a simple scope table updated per sprint
- Replace section 12 (schedule) with sprint-based testing cadence
- Automate section 9 — most deliverables are generated by CI/CD (coverage reports, execution results)
- Focus on sections 6-8 — approach, pass/fail, and suspension criteria are the most valuable sections for agile teams
The spirit of IEEE 829 — structured, traceable, explicit about scope and criteria — remains relevant regardless of methodology.
Key Takeaways
- IEEE 829 defines 14 sections for a comprehensive test plan
- Critical sections: features tested/not tested, approach, pass/fail criteria, and suspension criteria
- Adapt for agile by keeping it lightweight, living, and sprint-focused
- The standard provides structure for thinking about testing — even if you do not follow it literally
- Always state what is NOT tested — this prevents blame when untested areas have bugs