What this resource covers
Quality assurance shapes the process used to prevent and detect problems. Testing provides evidence about behavior and quality. A useful strategy selects test levels and depth according to business risk, architecture, change, data, and operating conditions.
- Trace tests to requirements, risks, interfaces, and acceptance criteria
- Use unit tests for focused logic and integration tests for boundaries
- Use system tests for complete workflows and role behavior
- Use regression tests to protect important existing behavior
- Plan security, performance, usability, recovery, and compatibility checks where relevant
- Control test data and environments
- Record defects with reproducible evidence and verify fixes
Information to prepare
Prepare requirements, risk areas, user journeys, architecture, interfaces, data variations, environments, supported devices, security concerns, release criteria, and known failure history.
- Requirements, acceptance criteria, architecture, and risk register
- Supported environments, devices, browsers, users, and data conditions
- Integration contracts and test access
- Release scope and changed components
- Quality and release criteria
Expected planning outputs
Produce a risk-based test strategy, traceable cases, test data and environments, automated and manual coverage, defect evidence, quality reporting, and release recommendations.
- Test strategy and coverage map
- Test cases, automated checks, and test data
- Execution and defect evidence
- Regression results
- Quality assessment and release recommendation
Practical example
How it can be applied
For billing, tests may cover calculations, permissions, invoice status changes, duplicate prevention, payment adjustments, reports, exports, audit entries, API failures, and regression of previously released customer workflows.
Common mistakes to avoid
- Beginning system testing only at the end
- Testing only expected success paths
- Using production-sensitive data without controls
- Counting test cases instead of evaluating risk coverage
- Closing defects without verifying the fix and affected regression
FAQ
Common questions
What determines testing depth?
Business impact, security, complexity, change size, integration exposure, user volume, data criticality, and release risk.
Can all testing be automated?
No. Automation is valuable for repeatable checks, while exploratory, usability, and some integration or operational evaluation still require human judgment.
Who is responsible for quality?
The whole delivery group contributes. Dedicated quality roles add expertise but do not remove responsibility from analysts, designers, developers, product owners, and operators.