Software quality assurance is the set of processes, standards and checks a team uses to make sure software meets agreed requirements and stays maintainable after release. It covers requirements, design, code, testing, release and maintenance, and it is as much about how the team works as about the tests it runs.
Teams that treat SQA as a testing phase at the end usually pay for it in rework, missed dates and production incidents. Teams that treat it as a lifecycle discipline catch expensive problems while they are still cheap to fix.
What software quality assurance covers across the lifecycle
SQA starts before a line of code is written. Each stage below has a quality question the team should answer before moving on.
- Requirements: every user story has testable acceptance criteria, and someone has written down what done means. Ambiguity here becomes a defect later, at ten times the cost.
- Design: architecture and API reviews, plus threat modelling for anything touching authentication, payments or personal data.
- Development: code review against an agreed checklist, static analysis in the pipeline, unit tests for business logic.
- Verification: integration, system, regression, performance and security testing, plus exploratory testing for the paths nobody wrote a script for.
- Release: a release checklist, user acceptance testing, a rollback plan and one named owner for the go/no-go decision.
- Maintenance: monitoring, defect trend review and a short post-incident write-up that feeds back into the process.
QA vs QC vs testing: what the difference actually is
The QA vs QC distinction confuses buying teams because the words are used interchangeably in job titles. The simplest split: QA is process-oriented and preventive, QC is product-oriented and detective, and testing is one of the activities QC uses to produce evidence.
| Aspect | Quality assurance | Quality control | Testing |
|---|---|---|---|
| Focus | The process that produces the software | The product against its standard | Specific checks that generate evidence |
| Direction | Preventive | Detective | Verification |
| Timing | All lifecycle stages | Before each release | At defined test levels |
| Owned by | Whole team, led by engineering management | QC and QA engineers | Testers and developers |
| Typical output | Standards, checklists, definition of done | Defect reports, release recommendation | Test results, pass or fail evidence |
In practice the labels matter less than the coverage. A team whose QA engineer only clicks through builds before release is doing QC, whatever the title says. Ask what process changes came out of the last two retrospectives; that tells you more than the org chart.
A practical software qa process in six steps
A workable software qa process is shorter than most templates suggest. What matters is that every step has an owner and a visible outcome.
- Agree the quality bar in the backlog. Acceptance criteria per story, and a written definition of done covering review, tests and documentation.
- Plan tests by risk. Rank features by impact and likelihood of failure, then put the deepest testing where damage would be worst: money, data, access control.
- Put gates in the pipeline. Required code review, static analysis and unit tests, with builds failing on agreed thresholds rather than on someone remembering to check.
- Test in layers. Unit tests for logic, integration tests for service contracts, a thin end-to-end suite for critical journeys, and exploratory sessions for everything else.
- Run one defect lifecycle. Severity and priority defined up front, one tracker, and a rule for who decides when a known defect is acceptable to ship.
- Review release readiness. Open defects, coverage of changed areas, migration plan, monitoring and rollback, all on one short checklist.
Quality metrics that change decisions
Track a small set of numbers and use them to change behaviour. A dashboard nobody acts on is a cost, not a control.
- Defect escape rate: bugs found in production compared with bugs found before release. This is the best single measure of whether pre-release checks work.
- Reopen rate: fixes that come back. High reopen rates usually point to unclear acceptance criteria rather than careless developers.
- Requirement coverage: how many acceptance criteria have at least one test, which is more useful than line coverage alone.
- Automated suite health: pass rate, and how often tests fail without a real defect. A flaky suite trains people to ignore red builds.
- Delivery stability: change failure rate and time to restore service, the measures popularised by the DORA research, connect quality to delivery performance.
Leave raw bug counts out of performance targets. Counting defects per developer almost always produces fewer reported defects, not fewer defects.
Where test automation pays off
Automation earns its keep when a check is repeated often, is expensive by hand, or must run on every change. Regression suites, API contract tests, validation across large data sets, and load or performance scenarios all fall into that group. Cross-browser and cross-device checks also pay off once the matrix stops fitting inside a manual release window.
It rarely pays off for one-off checks, screens still being redesigned every sprint, or anything requiring human judgement such as usability and visual quality. Automation also carries a running cost: every script must be maintained, and a test that fails for the wrong reason is worse than no test. Start with the highest-value regression paths and grow the suite only as fast as the team can keep it green.
When the internal team cannot keep up, software testing services from a partner can cover the regression layer while your engineers stay on product work.
| Good automation candidates | Poor automation candidates |
|---|---|
| Regression tests on stable features | Screens redesigned every sprint |
| API and service contract tests | Usability and visual judgement |
| Load and performance scenarios | One-off migration checks |
| Validation of large data sets | Exploratory testing of new features |
Ready-made software vs custom build, and QA in an outsourced team
The build-or-buy decision changes who carries the quality risk.
With ready-made software you inherit the vendor’s testing but still own integration quality: data migration, single sign-on, permissions, and how the product behaves under your real data volumes. Ask for their security practices and incident history, and run acceptance tests on your own data before signing a multi-year contract.
With custom software you own the quality of everything, including code written by someone else. That makes the partner’s process part of the purchase. In an outsourced team, look for:
- A written definition of done and review rules in the first weeks, not after the first incident.
- Tests committed with the feature in the same pull request, visible in your repository.
- CI that runs on every change and blocks merges when it fails.
- Defect data shared openly with you, including the defects found late.
- Named ownership of release decisions and a rollback plan for each release.
These are the same signals you would look for in-house. A partner that builds systems for a living, such as a custom software development services provider, should be able to show them in the repository and the contract rather than describe them in a slide.
Frequently asked questions
Is software quality assurance the same as testing?
No. Testing is one activity inside quality control, and QC is one part of quality assurance. SQA also covers requirements review, coding standards, code review, release management and how defects are analysed after release. A team can run thousands of tests and still have weak SQA if the same kinds of defects keep escaping to production.
How many QA engineers does a project need?
There is no fixed ratio, and anyone quoting one is guessing. It depends on the risk profile, how much of the suite is automated, how regulated the domain is and how often you release. Start with shared testing responsibility, measure defect escape rate for a few sprints, and add dedicated capacity where the numbers show a real gap.
How do you measure software quality without slowing delivery?
Use a handful of outcome metrics: defect escape rate, reopen rate, change failure rate and time to restore service. Collect them automatically from your tracker and pipeline instead of asking people to report them. Large manual gate reviews rarely catch more defects; they mostly lengthen the feedback loop.
What should you check when outsourcing QA or development?
Ask to see the definition of done, a recent pull request with its tests, the CI configuration and the last few months of defect data. Ask who owns the release decision and what happens when a defect reaches production. Teams with a working process answer quickly with artefacts; teams without one answer with assurances.
Conclusion
Software quality assurance is a management system for defects, not a phase at the end of the schedule. Teams that get it right agree the quality bar early, keep the feedback loop short, automate the repetitive checks and review the numbers that show whether defects are escaping.
If you are evaluating a partner, ask for evidence of that process rather than a promise of quality. The artefacts are easy to check once you know what to look for.
Planning a similar project? Zodinet Technology has built software for businesses since 2016. See our custom software development services or talk to an engineer.