Blog
Key takeaways:
Search for "quality assurance process" and you get manufacturing, aerospace, call centers and customer service, plus a lot of pages that use quality assurance and testing as synonyms. Very little of it tells a software team what to actually set up on Monday.
Somebody asked this directly in an r/QualityAssurance thread: a support rep moved temporarily into QA, told by their manager they would be fine as long as they followed the process, and never told what the process was. Their own summary, anecdotal but hard to argue with, was that searching for it did not help them understand what the thing is.
So this guide answers that question for a software team. It starts from the definitions the testing profession actually uses, because they change what you build, then walks through six parts of a process you can write down this week.
The confusion is worth clearing up first, because it determines where you spend effort. The ISTQB glossary, which draws these definitions from the ISO 24765 vocabulary standard, separates three terms that most articles merge.
| Term | ISTQB definition | When it happens | Nature |
|---|---|---|---|
| Quality assurance (QA) | Activities focused on providing confidence that quality requirements will be fulfilled | Mostly before and during build | Preventive |
| Quality control (QC) | Activities designed to evaluate the quality of a component or system | After something exists to evaluate | Detective |
| Testing | The process within the software development lifecycle that evaluates the quality of a component or system and related work products | After something exists to evaluate | Detective |
Read the first row again. Assurance is about confidence that requirements will be met, which is a claim about the future, and you cannot build confidence in the future by testing the past.
The three terms separate at one moment: when there is something to evaluate.
Testing sits inside quality control, which is why the glossary cross-references the two. So when a team says it has no QA process and means it has no test suite, it is describing a gap in control rather than assurance, and the two gaps have different fixes.
If quality assurance is preventive, then most of the process lives in the decisions made before a developer opens an editor. That reframes what you are building.
A detective-only setup finds defects late, when they are expensive, and its cost scales with how many defects you produce. A preventive setup reduces how many you produce in the first place: clearer requirements, agreed acceptance criteria, a definition of done nobody argues about, and design review on the parts that are hard to change later.
You need both halves. The mistake is assuming the detective half is the whole thing, because that is the half you can buy.
This also means your quality assurance process is shaped by how you deliver. A team on two-week iterations needs criteria that fit inside an iteration, and a team shipping daily needs gates that run automatically, which is one more reason the choice of software development methodology has consequences well past the stand-up format.
A process is a set of written agreements about who checks what, when, and what happens when a check fails. That is all. It is not a document management system and it does not require a certification.
Six parts cover almost every software team VAULT has worked with. Each one is a page or less, each one names an owner, and each one is useless if it lives only in somebody's head. The rest of this guide takes them in order, because they build on each other: you cannot write acceptance criteria before you have decided what quality means for your product, and you cannot set a release gate before you know what you test.
The six quality assurance steps are a definition of quality, acceptance criteria, test levels and coverage decisions, entry and exit criteria per stage, a defect triage rule, and a post-release feedback loop. Write them in that sequence and each one has what it needs.
A useful starting point is one question: what defines quality in your company? It is a better opening move than picking a tool.
The answer has to be specific to your product, because quality characteristics compete. A trading system prioritizes correctness and latency, a consumer app prioritizes interaction quality and reliability, and an internal reporting tool may accept a slow page in exchange for accurate numbers.
The third item there does more work than it looks like. A written decision not to optimize something is what stops a reviewer blocking a release over a goal the team never held.
Acceptance criteria are the most direct form of quality assurance available, because they turn a vague requirement into a checkable statement while changing it is still free. They also settle the argument about whether something is a bug or a missing feature, which otherwise consumes real time.
Write them as conditions that can only be true or false. "Search should be fast" is not a criterion. "Search returns results in under 500ms for a catalog of 10,000 items, and shows an empty state with a suggested action when there are no matches" is two criteria and a developer can tell when they are met.
Cover the unhappy paths explicitly. For every feature, state what happens on invalid input, on a failed third-party call, and when the user has permission to see some of the data but not all of it. Those three cases produce most defects found after release, and they are almost never in the original ticket.
One of those is written down and three of them are assumed.
Acceptance criteria are also what make a requirements document worth writing rather than filing, since a product requirements document without them records intent and settles nothing.
Coverage arguments go in circles because teams debate a percentage instead of deciding which risks need which kind of check. Decide by level, then by risk.
Unit tests are cheap, fast and narrow, so they belong on the logic that encodes your business rules: pricing, permissions, calculations, state transitions. Integration tests cover the seams where your code meets a database, a queue or a third-party API, which is where assumptions diverge. End-to-end tests are slow and brittle, so reserve them for a small number of paths you cannot afford to break, such as signup, checkout and anything that moves money.
The harder decision is what you will not automate. Visual polish, copy, and judgments about whether a flow feels right are cheaper to check by eye, and a brittle test that fails randomly costs more than the bug it was written to catch.
The toolchain matters less than the decision, and most teams already own more capability than they use, which is the recurring finding whenever we audit a stack of application development tools a client has accumulated.
Entry and exit criteria are the part of a quality assurance process that most teams skip, and they are what turns good intentions into a gate. An exit criterion says what must be true before work leaves a stage. An entry criterion says what must be true before it is accepted into the next one.
The two criteria are different questions asked at the same line.
Criteria like these work because they move the conversation off opinion. Nobody has to argue about whether a feature is ready when the list is on the wall.
The last two are the ones that save weekends. A release gate that checks only for defects assumes the deployment will work, and the cost of that assumption shows up at the worst possible time.
Entry criteria also stop the most common waste in software delivery, which is work starting before anybody has agreed what it is. If you are not sure a piece of work is ready to build at all, that is a validation question rather than a testing one, and the distinction between a proof of concept vs prototype tells you which kind of answer you still need.
Defect triage goes wrong when severity and priority get treated as one field. Severity is how badly the software is behaving. Priority is how soon you will do something about it. They are set by different people for different reasons, and keeping them separate ends most triage arguments.
| Severity | What it means | Typical priority | Action |
|---|---|---|---|
| Critical | Data loss, security exposure, or the core flow is unusable | Immediate | Stop other work, fix and release out of band |
| High | A main feature is broken with no workaround | Current iteration | Fix before the next release ships |
| Medium | A feature is broken but a workaround exists | Next iteration or two | Scheduled, with the workaround documented for support |
| Low | Cosmetic, or affects a rarely used path | Backlog | Batched with related work, or closed deliberately |
Write the severity definitions down once and apply them mechanically, because the value is in consistency rather than precision. A team that classifies the same way every time can see whether its defect profile is getting better.
Closing a low-severity defect deliberately is a legitimate outcome and worth saying out loud. A backlog of 400 cosmetic issues nobody will ever fix says little about quality, and it makes the defects that matter harder to find.
Everything up to here is a prediction about what users will experience. The loop closes when you check the prediction, and most quality assurance processes stop one step short of this.
Pick a small number of signals and look at them on a schedule. The point is to detect a quality problem your process missed, so the signals you want are the ones users generate rather than the ones your test suite reports.
Feed what you find back into the earlier steps rather than into a report. A cluster of tickets on one feature usually means its acceptance criteria missed a case, which is a step two problem, so the fix is a better criterion next time rather than more testing of the same thing.
Every signal on that list is generated outside the process that was supposed to catch it.
None of these signals come from your test suite, which is the point. Your process can only catch the problems it was shaped to look for, so letting users guide you after launch is how you find the rest.
The economics of this changed recently, and there is measured evidence rather than opinion. Google's DORA program surveyed 4,867 technology professionals for its 2025 report on AI-assisted software development, and 90 percent of them use AI at work.
Its findings on AI are two-sided. Respondents with higher AI adoption report higher code quality, and AI adoption is now associated with higher software delivery throughput, which reverses the negative relationship DORA reported in 2024. More than 80 percent of respondents believe AI has increased their productivity, though 30 percent report little to no trust in the code it generates.
Stability has not followed. The same report finds AI adoption still associated with increasing delivery instability, which DORA measures from change failure rate and rework rate. Those are quality control measures. So the research suggests that teams are shipping more, and faster, while the rate at which changes fail or have to be redone is rising too.
That is a quality assurance problem rather than a tooling problem. More code is arriving, written faster, by a process that produces plausible-looking output, which puts the weight onto the gates.
The gates that matter are acceptance criteria specifying behavior precisely, review by someone who understands the business rule, and tests that assert the rule rather than the implementation. It also means more dependencies arriving without anyone deciding to add them, and an unreviewed dependency is a web application security problem before it is ever a quality one.
At VAULT, AI-assisted code on client projects goes through the same gates as any other code, with no shortcut for having been generated. It needs acceptance criteria written before anything is generated, review by someone who understands the business rule it touches, tests that assert that rule, and an explicit decision before any new dependency it introduces is merged.
Most teams we work with have no dedicated QA role, and in practice the work gets distributed rather than skipped. Developers own unit and integration tests. Whoever wrote the acceptance criteria confirms they are met. One person owns the release gate each cycle, and that rotates.
The pattern that scales is to automate every check that runs on every change, then spend human attention on risk-based sampling rather than full manual regression. People are better at noticing that something is odd than at repeating a 90-step script for the fortieth time.
Honest Game put us on the other side of that question. Automating their NCAA eligibility reports meant their staff stopped producing every report and started spot-checking the output, which replaces one quality control activity with a different one rather than removing it.
The design work in any move like that is the sampling rule. Somebody has to decide which outputs get checked, on what basis, and what happens when a sampled one is wrong, because a sample chosen by convenience tells you nothing about the population.
Weighting toward the inputs most likely to produce an ambiguous result beats a flat percentage, since a fixed one-in-twenty check spends most of its attention on the easy cases. What made that tractable for the Honest Game build was that the mapping rules were explicit enough to tell an ambiguous transcript from a straightforward one.
Write the six parts down this week, in order, and keep each one to a page. A definition of quality, acceptance criteria, the test levels you have chosen, entry and exit criteria per stage, your severity definitions, and the handful of post-release signals you will watch.
After that, do the one thing that actually determines whether it works: give every part a named owner and a review date. Processes do not decay because they were badly designed, they decay because nobody was responsible for them and nothing forced a second look.
We help teams build this alongside the product rather than after it, since retrofitting quality gates onto a codebase with no tests and no acceptance criteria is the expensive version. Much of it is a design problem as much as an engineering one, which is why our design practice treats validation and prototyping as part of delivery rather than a phase before it.
It is the set of agreements that give a team confidence its quality requirements will be met, which in the ISTQB vocabulary makes it preventive work and separates it from quality control, where you evaluate what has already been built.
In practice the agreements cover what quality means for your product, how requirements get written, which levels you test at, what must be true to move between stages, how defects are classified, and what you watch once a release is out.
Six quality assurance steps cover most software teams, and the order matters because each one depends on the last. Start by agreeing what quality means here, then turn requirements into checkable conditions, then choose your test levels by risk. From there, gate the movement between stages, classify defects by a written rule, and check real usage after release. Each step needs a named owner to survive past the month you wrote it.
Quality assurance is the preventive half and testing is part of the detective half. ISTQB places testing within quality control, defining it as the process that evaluates the quality of a component or system. So a quality assurance testing process is one component of a full quality assurance process, covering how you verify what exists rather than how you reduce the number of defects created.
The parts are the same, but they have to fit inside an iteration. Acceptance criteria get written per story rather than per release, entry and exit criteria run as automated checks instead of stage-gate meetings, and the post-release loop runs continuously because releases are frequent. The main failure mode is dropping entry criteria entirely in the name of speed, which lets underspecified work into development and shows up later as rework.
Improve it from evidence your process produced rather than from a maturity model. Track your change failure rate, the share of releases needing a fix within 48 hours, and where support tickets cluster, then trace each problem back to the step that should have caught it. A defect pattern usually points at vague acceptance criteria rather than insufficient testing, so changing step two often beats adding more tests at step three.
Most quality problems we find are traceable to one missing agreement rather than a missing tool: criteria nobody wrote, a gate nobody owns, or a definition of done that two people read differently.
If you want help working out which of the six is actually failing on your team, contact us. Bring the part of your release process nobody feels confident about.
