What quality assurance means
Quality assurance (QA) is the set of planned activities that aim to give confidence that a project will meet its quality requirements. The key word is process. QA looks at how the work is done, on the idea that a well-run process is more likely to produce a good result than a careless one followed by heavy checking.
This is the main difference from quality control, which examines the product itself through inspection and testing. The two work together, and the quality control article on this site covers the product side in detail. Here the focus is on prevention: arranging the work so that defects are less likely to be introduced and are noticed early when they are.
“QA” is also used loosely in some software teams to mean a testing role. That is a common usage, but in quality management the term refers to the broader process view described here. It helps to know which meaning is intended when a job description or a meeting uses the term.
Why prevention is usually cheaper
A defect found while a requirement is still being written is typically cheap to fix: someone edits a sentence. The same defect found after parts are built or code is shipped often means rework, delays and sometimes recalls or safety concerns. The exact cost ratios vary widely between industries and projects, so treat any single figure you read with caution. The general direction, that later fixes tend to cost more, is widely accepted.
Prevention also protects people. In areas such as medical devices, vehicles, construction or industrial equipment, a defect may be a safety issue rather than only an inconvenience. QA is one of the ways an organisation shows it has taken reasonable care.
The building blocks of a QA approach
A quality plan
A quality plan states what “good” means for this project and how the team intends to reach it. It commonly covers:
- the quality requirements and the standards or regulations that apply
- who is responsible for which checks
- which reviews, tests and approvals happen at which stage
- how problems are recorded and followed up
- what records will be kept
The plan should be proportionate. A small internal tool does not need the same paperwork as a safety-related product, but it still benefits from writing down what the team agreed to do.
Clear inputs
Many defects start as unclear or missing needs. Good practice in requirements engineering reduces this, and well-written technical specifications give everyone the same definition of the work. If people cannot say how a requirement would be checked, QA usually asks for it to be rewritten.
Standards and procedures
Standards capture what many practitioners have found works. Some are about management systems, such as the ISO 9001 family for quality management, and others are specific to an industry, a product type or a programming environment. Which ones apply depends on your country, your industry, your customers and sometimes the law. Do not assume a standard applies, or does not, without checking with the people responsible in your organisation. Reading a standard summary online is not a substitute for the standard itself or for qualified advice.
Procedures turn standards into daily practice. Clear written procedures help new team members do routine tasks in a consistent way.
Reviews
Reviews are among the most practical QA tools because they catch problems before anything is built. Examples include design reviews at key stages, peer code review in software, and checking of calculations and drawings by a second person. A review is more useful when it has a stated purpose, the material is circulated beforehand, and findings are recorded and tracked to closure instead of being discussed and forgotten.
Traceability and records
When a customer, regulator or colleague asks why something was done a certain way, records provide the answer. Requirements traceability links each requirement to the design element and test that address it, which makes gaps visible. Good documentation practice also means the next person can understand what was decided and why.
Audits
An audit is a structured, usually independent, examination of whether the project or organisation is following its own process and the standards it committed to. Audits look for evidence: records, samples of work, and how people describe what they do. They are not meant to assign personal blame. Findings are typically recorded as nonconformities or observations, and the team then agrees corrective actions.
Handling problems when they occur
Even a good process will not prevent every defect. A QA approach includes a way to record problems, find out why they happened, and change the process so they are less likely to recur. Fixing the single instance without asking why is a common trap. Methods such as root cause analysis help here, and over time the lessons feed into continuous improvement of the process itself.
A healthy safety culture matters as well. People need to feel able to report errors and doubts early, because a QA system that relies on hidden problems being discovered by accident is not providing much assurance.
Common pitfalls
- Paperwork without purpose. Producing documents to satisfy an audit, while the real work follows a different path, adds cost and little value.
- QA as a final gate. If quality is only considered at the end, there is little left to prevent.
- Treating testing as the whole of QA. Software testing and other inspection are important, but they come after many of the decisions that shape quality.
- No ownership. If everyone assumes someone else is checking, nobody is.
- Copying another organisation’s process unchanged. A process fitted to a different product, size or risk level may be too heavy or too light for you.
Getting started in a small team
You do not need a formal system to begin. A reasonable first step is to write a one-page plan: what the project must achieve, which checks will happen and who will do them, and where results will be recorded. Add a review at each major stage, keep a simple log of defects and their causes, and look through that log periodically for patterns. As the work grows in risk or scale, extend the process, and follow the standards and professional guidance that apply to your field and country.
This article is general educational information. It is not professional engineering, legal or compliance advice, and requirements differ between industries and jurisdictions.