Ask a team what quality assurance covers and you’ll get a description of testing. Testing is one activity inside it, and the smallest part of the job.
Software quality assurance is the standing agreement about how work gets checked, by whom, and against what, settled before a single test runs. It sets the bar. Testing measures the build against it.
That distinction isn’t academic. It decides whether a team spends its time fixing defects or fixing the reason defects keep arriving.
Key Takeaways
- Quality assurance sets the standard; testing checks a build against it.
- Exit criteria agreed before the work starts are what end the release argument.
- A defect class that escapes twice is a process failure, not a testing failure.
Quality Assurance and Quality Control Do Different Jobs
Quality assurance works on the process. Quality control works on the product.
That’s the whole distinction, and it’s the one teams collapse the moment they hire for a QA role and hand the person a test plan.
| Question | Quality assurance | Quality control |
|---|---|---|
| What it acts on | The process | One build |
| When it happens | Before and during the work | After the work exists |
| Who owns it | Everyone who ships | Whoever runs the checks |
| What it produces | Standards, criteria, reviews | Defect reports, test results |
| How it fails | Rules nobody applies | Tests that pass on broken behavior |
A team with strong control and no assurance ships a clean build every time, and never finds out why the last three needed an emergency patch.
What Quality Assurance Owns in the Delivery Cycle
Quality assurance owns the checkpoints, not the code.
Each stage of delivery hands something to the next one. Assurance is the written agreement about what a stage must be able to show before it hands over.
Entry and Exit Criteria
Entry criteria say what a stage needs before work can start on it. Exit criteria say what it must show before the work moves on.
Written down, they end the argument. Left undocumented, the argument happens the day before release, and the loudest person in the room wins it.
Reviews Before Tests
A design review catches the defect while there is still no code to test.
That’s the cheapest place a defect ever gets caught, because nothing has been built on top of it yet and no other team has started depending on it.
Security work follows the same shape. A team already running a secure software development life cycle has most of its assurance checkpoints in place already, because phase gates are exactly what those are.
Who Runs Quality Assurance
Quality assurance runs on the people who build the software, coordinated by someone who owns the rules.
The common failure is hiring one QA engineer and treating that person as the place quality happens. Nobody can assure a process they don’t take part in.
Developers Own Prevention
Developers write the tests that run on every commit, and they set what a definition of done includes.
Neither of those moves to a separate team without quality dropping, because the person who wrote the code knows what it’s likely to get wrong.
The QA Lead Owns the Rules
Someone has to decide what gets checked, hold the exit criteria, and say no when a release misses them.
That’s an authority problem before it’s a skills problem. A QA lead who cannot stop a release is a reporting function with a misleading title.
Put that authority where the rest of the decisions live. A team that has already worked out how to manage software projects with one named owner per decision has somewhere to record it.
What Quality Assurance Hands Over
Quality assurance produces documents, and the documents are the point.
A process that exists only in someone’s head is a habit rather than assurance, and habits leave with the person who had them.
Four artifacts do most of the work:
- A quality plan naming what gets checked at each stage.
- Entry and exit criteria per stage, agreed before the work starts.
- A defect record carrying severity, owner, and where the defect was introduced.
- A release note stating what was checked and what was knowingly left.
The third one earns its keep twice. It tells you what to fix now, and grouping it by software bug types shows which part of the process keeps producing the same class of defect.
That record needs one home. Bug tracking software holds severity, owner and introduction point on the same row, which is what makes the pattern visible at all.
How to Tell Whether Quality Assurance Is Working
You look at repeat defects, not at pass rates.
A pass rate measures the tests you wrote. It says nothing about the ones you didn’t think to write, and that is where escaped defects come from.
Two signals tell the truth.
The same defect class appearing in three consecutive releases means the process producing it hasn’t changed, whatever the test suite says.
A defect a customer found, which your exit criteria said would be caught, means the criteria are decoration.
Questions Teams Ask About Quality Assurance
What is software quality assurance in simple terms?
Software quality assurance is the set of standing rules that decide how work gets checked before it ships. It covers standards, entry and exit criteria, reviews, and who holds the authority to stop a release. Testing is one activity carried out under those rules.
What is the difference between quality assurance and quality control?
The difference is what each one acts on. Quality assurance works on the process that produces builds, and quality control works on one build. Assurance asks whether a team’s way of working reliably produces working software; control asks whether this build works.
Is quality assurance the same as testing?
No. Testing is a quality control activity that measures a build against a standard. Quality assurance is what sets the standard, decides where the check happens, and names the person who can refuse a release.
Who is responsible for software quality assurance?
Everyone who ships is responsible, and one person owns the rules. Developers own prevention through the tests they write and the definition of done they agree to. A QA lead owns the criteria, and needs real authority to hold a release, or the criteria get waived the first time a date is at risk.
What documents does software quality assurance produce?
It produces four: a quality plan, entry and exit criteria per stage, a defect record, and a release note saying what was checked and what was left. A process that lives only in someone’s head isn’t assurance, because it leaves with that person.
Most QA Problems Are Authority Problems
Teams rarely fail at quality because nobody knew what good looked like.
They fail because the person holding the criteria couldn’t stop the release, and the criteria got waived enough times that nobody kept writing them.
So the fix isn’t a bigger test suite. Write the exit criteria for the next release, name the person who can refuse it, and watch whether that name survives the first date under pressure.
Add SocialAtoZ as a preferred source
See us more often in your Google results.
