What is QA (Quality Assurance) in software, made simple

QA (Quality Assurance) is the set of practices that give you a way to know, before you ship, whether the software does what you promised. That is the short answer. The long answer is that QA is not the moment when someone "checks to see if it works": it is the system that makes quality predictable instead of a last-minute surprise.

The popular image of QA is a person who breaks things right before launch. They find defects, report them, and everyone scrambles to fix them. That person exists and is needed, but confusing that with QA is like confusing the firefighter with fire safety. Putting out the fire is necessary once there is a fire. QA, properly understood, is the work that makes fire rare.

01 · the confusionQA is not "the one who breaks things at the end"

We need to separate three words that are often used as synonyms but are not: quality, assurance, and testing. Quality is a property of the product: how well it does what it should. Assurance (the A in QA) is the process that works to make sure that property holds. And testing is one of the activities inside that process, not the whole process.

The international standard that defines what "quality" means in a software product is called ISO/IEC 25010. It does not talk about "no bugs". It talks about measurable characteristics: functional suitability, reliability, performance efficiency, usability, security, compatibility, maintainability, and portability [1]. A product can have not a single visible error and still be of poor quality if it is insecure, impossible to maintain, or incomprehensible to whoever uses it.

Testing at the end tells you what broke. QA decides, from the very start, what should never be able to break.

That is why QA starts long before there is any code to test. It starts when someone writes down what the software must do and under what conditions it will be considered correct. Without that prior agreement, "testing" is just opinion. With it, testing becomes verification.

02 · the systemPreventing is cheaper than correcting

The economic reason QA moves ahead of the end has decades of evidence behind it. A defect costs more the later it is discovered. A poorly written requirement, if caught while it is still a sentence in a document, costs the price of correcting a sentence. That same poorly written requirement, discovered when it is already code in production that a customer relies on, costs rework in code, data, communication, and trust. The rule of thumb popularized by Barry Boehm is that the cost of fixing a defect grows sharply as the project advances [2].

From there comes the central idea of assurance: move the care for quality toward the beginning instead of leaving it for the end. In practice, that means several activities that do not look like "testing" and yet are pure QA:

Define the criterion before building. Before writing code, you write down what will count as "done" and "correct". That criterion is the oracle: the reference you later verify against. Without an oracle, no one can claim something passed or failed, only that "it looks fine".

Review, do not just run. Reading an ambiguous requirement and asking for clarification is QA. Reviewing a design and spotting that it does not account for a case is QA. None of that runs the program, and it still prevents defects that would cost far more later.

Verify against the criterion. This is where testing comes in: running the software and comparing its behavior to what was agreed. This is the visible part of QA, the one people recognize, but it is the tip of the iceberg resting on everything above.

03 · the Qirava approachQuality is a system, not last-minute heroics

All of this leads to a conclusion many teams find uncomfortable: if quality depends on a brave person finding the defects in time the night before launch, you do not have quality, you have luck. And luck does not scale. It works until the day that person is on vacation, or the product grows faster than a single pair of eyes can review.

At Qirava we treat quality as a system with rules, not as an act of heroism. A system has three things heroism does not: it is repeatable, it is explainable, and it does not depend on who is on shift. When a defect slips through, the question is not "who failed to test it", but "what part of the system let it get this far without anyone noticing". That question fixes the process; the other one only looks for someone to blame.

If quality depends on someone being heroic the night before launch, you do not have quality: you have luck.

That system rests on a foundation we already covered in other articles: writing the specification before the code, so there is a criterion to verify against. Without a specification there is no possible QA, only opinions about whether something "looks fine". With a specification, every claim about quality becomes checkable.

04 · in one sentenceWhat to take away

QA is the discipline of knowing, before you ship, whether the software meets what you promised, and of organizing the work so that meeting it becomes the norm and not a stroke of luck. Testing at the end is one part, the most visible, but it is the tip of something bigger: define the criterion, review it, build against it, and verify without drama.

The image of the hero who breaks things on the last night is endearing and misleading. Real quality is boring in the good sense: systematic, early, and repeatable. When it works, you barely notice it, because the fires it puts out are the ones that never happened.