This article delves into the roles of QA and QC in software development. It highlights the differences between the two, who can perform these roles, and why they are essential in the production of good software and code.
What is the difference between QA and QC?
- Quality Control (QC) means testing a product to uncover defects and reporting them to whom will decide to allow or deny the product release.
- QC is done in a controlled condition, both “normal” and “abnormal”.
QC should intentionally attempt to make things break. QC addresses the ‘detection’ of issues.
- Quality Assurance (QA), on the other hand, aims to improve and stabilise the production itself. QA analyses issues that led to the defect(s) in the first place and attempts to ensure those do not happen again. QA might also detect potential problems that could surge from a new process and try to avoid them.
QA makes sure that any agreed-upon processes, standards and procedures are defined and followed. QA addresses to ‘prevention’ of issues.
Who can do QA and QC?
Humans do QA.
A so-called “QA Engineer” understands the development process and how it can fit the organisation’s goals.
QA Engineers supervise code development, scan for potential issues, and make sure the Company Goal still is met.
Experienced Coders with insight into the company “business” are best for this task.
Of course, skills like diplomacy, being able to see things relatively, communication and Code understanding are necessary.
Humans AND machines do QC.
While I will not elaborate on Machine-driven QC (such as unit tests), it is essential to know who (or what) can do QC.
QC Engineers have a ‘test to break’ attitude.
They must be strong (active) users of the Product tested.
The best QA Engineer must actively build things with the tested Product. Not just support or develop it, but use it for their projects.
A QC Engineer must not have a great understanding of Code, but must be able to communicate the problems so a Developer can understand them; therefore, a background in programming or at least Supporting is good.
But mainly, a QC engineer is a sort of “advanced user” with the task to try to break the Product (Maybe according to a step by step sheet, but not necessarily).
QC uses the Product actively and understands the need for a safe and stable solution (as a user).
QC does not need insight into business goals, as QA and management decide whether to improve, add, or solve.
Also, since QA avoids significant functionality breaks and especially regressions (along with the Machine QC), the Human QC can focus on the “test to break” task.
QC happens with the end-user in mind. A user usually does not create a new website just because plugins update; instead they want to have a painless update process without any issue popping up.
Why do are QA and QC required when producing Software.
Also, why do we need designated Peoples doing it?
This is a question to answer with another question:
Why does Software have bugs?
There are a few significant reasons for this.
- miscommunication or no communication.
- software complexity.
- programming errors.
- time pressures and workload (not focused tasks).
- egos of developers.
- poorly designed/documented Code
- software development tools
You may say all this can be avoided by simply not making errors đŸ™‚
However, we are humans and make mistakes.
That is why QA needs to supervise, and Human QC needs to test.
The simple reason why we need QA and QC is that, after a proper development cycle and QA/QC, you have (or are close to) “Good Software and Good Code.”
What is “Good Software and Good Code”?
Quality software aims to be Bug-Free.
Bug Freee Software is Software that you install, no matter if for the first or “nth” time, and start using it according to the “how-to” document.
No surprises come up.
Good Software also provides the features you are looking for (as the user) and is affordable.
Good Software is only possible with Good Code.
‘Good code’ is Code that does what it is made for, is bug-free, secure, readable (commented and documented) and maintainable (not restricted to current situation or application).