Let's consider a sad yet common situation a failing project, the case with over 50% of IT projects in 2016.
Somewhere in the software development life cycle (SDLC), there comes a moment you understand that something went wrong. Badly wrong.
Observing a pitiful state of the project large technical debt, endless bug fixes that only generate more bugs and gloomy faces of the team members, who can't figure out what to do next, you can't stop thinking, 'How on earth did we land here? We've got a large QA team, so everything should, no, must be fine.' Hold on. Are you sure your team really does quality assurance (QA) and not quality control (QC) alone? We'll try to sort it out.
If you do believe that QA and QC are just the same thing, you've fallen a victim of a common misunderstanding. It occurs due to the fact that QA and QC are tightly connected. And it's Q the quality that actually unites the two concepts.
According to ISO 9001:2015, quality is a degree to which the product's characteristics meet the customer's requirements. This degree has three possible implementations:
- High the requirements are exceeded
- Medium the acceptable requirements are met
- Low the requirements are not met.
Both QA and QC aim at ensuring that the product at least meets the requirements. However, they approach the matter differently.
QC is all about the product. QC checks the product compliance to the project requirements to ensure at least acceptable quality of the deliverable with the help of numerous types of testing, which depend on the product (web application, mobile app, CRM solution or other). QC starts together with the development stage. It has a reactive character and considers the product quality at a given moment.
QA is aimed at ensuring that the project processes, including QC, are efficient for the delivery of a product of at least acceptable quality. Unlike QC, QA is process-oriented. QA is most efficient when started at the project planning stage or after a project milestone (e.g. an iteration). In this case, QA may help to prevent defects and avoid costly rework. However, in most cases, project teams turn to QA when the project is already in trouble. In this case, QA helps straighten up the project processes, fix the damage done, optimize the cost of rework and (if needed) educate the QC team.
We sum up the key features of the two quality management elements in the table:
Though tightly connected, QA and QC significantly differ in their perspective. It's like taking a picture of one and the same object, but from different angles. We explore these angles below.
QA covers the whole project starting with the planning stage. QA elements include compliance to quality management standards, knowledge transfer management, test data adequacy and some elements that seemingly have much in common with QC. Below we compare these elements in QA and QC:
- Requirement quality
In QC, testing engineers look at the requirement quality from the point of view of their testability. In other words, each requirement should be drafted to fit a certain test case. In case a requirement can't be transformed in a test case, it is considered faulty.
In their turn, QA consulting specialists focus on the compliance of the project requirements with the standard and ensure that the requirements are complete, consistent, clear, well-structured, modifiable and traceable. When QA efforts start early, they help detect faulty requirements swiftly, which can reduce the cost of rework.
- Systematic process improvement
While your testing team may continuously discuss testing process improvement, what they most likely mean is improving test coverage and testing methods. These purely QC elements have nothing to do with the project process.
Systematic process improvement is specific for quality assurance. Analyzing the available data, audit findings and various project reviews, QA consultants propose measures for continual improvement of the project process. These measures may be corrective, preventive or combined. This is the case in the majority of projects.
To assess the project process, QA consultants rely on domain specifics, their experience and a range of quality metrics. These metrics describe the quality of various project components (requirements, QC quality and the overall project quality) and organizational processes.
QA and QC metrics groups: The three pillars
The three central groups of QA and QC metrics coincide, which is another cause of term confusion. The groups in question are requirements metrics, test design metrics and defect metrics. Let's see how QA and QC apply these metrics, changing the focus depending on their goals:
- Requirements metrics. For QC, these metrics verify that each functional and non-functional requirement is covered with a test case or a script. QA has a broader focus, as certain requirements (e.g. HIPAA compliance) may be addressed in the architecture, deployment process, etc.
- Test execution metrics. These metrics examine testing progress considering the percentage of passed, failed and blocked test cases. Testing engineers report the metrics from iteration to iteration and draw conclusions about the quality of the product at a given moment. QA consultants look at how well test cases cover the project requirements observed at every SDLC stage.
- Defect metrics. For QC efforts, this group considers the severity of standing defects. As the project proceeds, the overall number of standing defects as well as defect severity should drop and vanish. However, it's not always the case and this is where QA approach can help. QA consultants perform trend analysis considering defect density per requirement as well as defect removal efficiency (Number of defects found / number of standing defects + defects found by end-users). These two indicators give a clear idea about the quality of the system.
Though QA and QC use the same groups of metrics, their focal points differ. For QC, the metrics provide valuable data for assessing the system quality at a given moment and adapting testing efforts accordingly. For QA, the metrics make a powerful tool providing a clear view of the project process quality throughout the SDLC. The metrics also help in detecting process bottlenecks and working out effective solutions.
Project sponsors and PMs often believe they have QA in their project, while what they actually have is QC (testing) only. This misunderstanding may well drive the project off the cliff, as the team miss several QA elements (compliance with quality management standards, knowledge transfer management and test data adequacy). In all fairness, drawing a line between QA and QC may be difficult even for professionals. Both QA and QC describe the project quality, and this accounts for the confusion around the two terms. So what are the key differences?
- While QC is focused on the product quality at a given moment, QA covers the quality of the overall project process. This makes QC or testing an integral part of QA, which considers quality at every SDLC stage from requirement gathering to maintenance and support.
- QA has a broader focus than QC. QA specialists don't look for bugs; they look for faults in the project process, which are often the root cause of project failures.
We hope that now the differences between QA and QC are clearer. Stay tuned for our next article on QA consulting.
We help companies to establish effective and structured QA processes considering business and industry specifics, develop a QA strategy, conduct QA audit and find ways to reduce QA expenses.