Quality assurance (QA) in software is the set of planned, systematic activities that give confidence that a product and the process producing it will meet defined quality requirements. In software quality, QA is process-oriented: it aims to prevent defects by shaping how software is specified, built, reviewed and released, rather than only finding defects after the fact.
QA is often equated with testing, but testing is only one of its tools. A QA function also defines standards, reviews, metrics and process improvements, and it answers a management question: how sure can we be that this release is good enough to ship?
What quality assurance covers
Quality assurance covers the whole development process, from requirements to release and operations. Its core idea is that consistent processes produce consistent results: if requirements are reviewed, code is checked and releases follow defined criteria, the product is less likely to contain serious defects.
- Quality planning: defining quality goals, acceptance criteria and the activities that will verify them.
- Standards and guidelines: coding standards, definition of done, review checklists.
- Reviews and audits: requirement reviews, design reviews, code reviews and process audits.
- Verification and validation: testing at unit, integration, system and acceptance levels.
- Measurement and improvement: collecting quality metrics and running root cause analysis on failures.
The scope reaches past development into feedback from production. Bug reports, crash reports and telemetry show where the process let defects through, and a mature QA function feeds these findings back into prevention measures such as new review rules or automated checks.
Quality assurance, quality control and testing
The three terms describe different levels of the same goal. Quality assurance manages the process, quality control (QC) inspects the product, and software testing is the main technique QC uses to execute software and compare results with expectations.
| Aspect | Quality assurance | Quality control | Software testing |
|---|---|---|---|
| Orientation | Process | Product | Product behavior |
| Goal | Prevent defects | Detect defects | Reveal failures |
| Timing | Throughout the life cycle | At checkpoints | During and after implementation |
| Typical activities | Standards, audits, metrics | Inspections, reviews, testing | Test design and execution |
| Responsibility | Whole team and management | Reviewers and testers | Testers and developers |
In everyday job titles, a QA engineer often performs mostly testing work. The distinction still matters: an organization that only tests, without improving the process, keeps finding the same types of defects release after release.
Quality models and standards
QA needs a definition of quality that can be measured. The most widely used reference is the ISO/IEC 25010 product quality model, part of the SQuaRE family, which breaks quality into characteristics such as functional suitability, performance efficiency, compatibility, reliability, security and maintainability.
| Standard or framework | Focus | Use in QA |
|---|---|---|
| ISO/IEC 25010 | Product quality characteristics | Defining measurable quality requirements |
| ISO 9001 | Quality management systems | Organization-wide process control |
| ISO/IEC/IEEE 29119 | Software testing processes | Structuring test policy and documentation |
| CMMI | Process maturity levels | Assessing and improving development processes |
| IEEE 730 | Software quality assurance processes | Planning QA activities for a project |
Regulated domains add their own expectations, for example medical device and automotive software standards that demand traceability from each requirement to its verification. In such environments, QA documentation is evidence for auditors, not optional paperwork.
Metrics that quality assurance relies on
QA decisions should rest on measured indicators rather than impressions. No single metric captures quality, so teams combine process and product measures and watch their trends over time, not individual values.
| Metric | What it measures | Warning sign |
|---|---|---|
| Defect escape rate | Share of defects found after release | Rising trend across releases |
| Defect density | Defects per size unit, such as per thousand lines | Hotspots in specific modules |
| Test coverage | Code or requirements exercised by tests | Critical paths left untested |
| Change failure rate | Deployments that cause incidents | Frequent rollbacks or hotfixes |
| Mean time to restore | Time to recover from a failure | Long outages after defects |
Metrics can be gamed. A coverage target of 100 percent encourages tests that execute code without checking results, so QA leads should treat metrics as signals for investigation, not as targets that end the discussion.
Quality assurance in agile and DevOps teams
In agile and DevOps teams, QA moves from a separate department at the end of the cycle to a shared responsibility built into daily work. This shift is often called shift-left testing: quality activities happen as early as possible, during refinement, design and coding.
Typical practices include acceptance criteria written before coding, automated unit and integration tests in the continuous integration pipeline, static code analysis on every commit and quality gates that block a merge when checks fail. QA specialists then focus on test strategy, exploratory testing and risk analysis instead of repetitive manual checks.
Common QA mistakes
The most damaging mistake is treating QA as a final gate that can compensate for weak development practices. By the time a system test finds a design flaw, the fix is expensive and the release date is at risk. Other recurring problems include automating unstable tests, ignoring non-functional requirements such as performance and security, and closing defects without understanding their root cause.
A subtler mistake is measuring QA by the number of defects found. That number rewards late detection and creates tension between testers and developers. A healthier goal is fewer defects created, supported by early reviews, clear requirements and a team culture in which anyone may stop a release that does not meet the agreed criteria.
In simple terms
Quality assurance is about making good software on purpose, not by luck. Think of a restaurant kitchen: tasting each plate before it leaves is useful, but a good kitchen also trains its cooks, keeps clean workstations and uses tested recipes so that bad plates rarely happen.
Testing is the tasting. Quality assurance is the whole system that makes the kitchen reliable, including learning from every dish that came back.
A practical example
A company that develops a mobile banking app sees several serious defects reach customers in one quarter, each followed by an urgent hotfix. A root cause analysis shows that most of them came from unclear requirements around currency rounding and from untested error handling.
The QA lead introduces requirement reviews with testers, a rule that every story needs written acceptance criteria, automated tests for all calculation logic and a quality gate that blocks merges below agreed coverage for critical modules. Defect escape rate becomes a release metric reviewed by management.
Over the following releases, fewer defects reach production and hotfixes become rare. The team ships with measurable confidence instead of relying on a last-minute manual test round.