In several articles and books I learnt that “V-model introduced QA into SW development”.
I would like to understand the point of such statement, as from my understanding, V model activities (verification and validation) cannot be considered as QA as both deal directly with product control, no matter if it’s static (verification) or dynamic (validation).
I would agree that testing (say V&V) is a tool used by QA to measure the quality, but how does it assure it?
Examples in Google Books:
“Real-Time Systems Design and Analysis: Tools for the Practitioner”.“..these QA activities form the heart of the V model…“
or
Iterative Software Engineering for Multiagent Systems: The MASSIVE..:
the V-Model adds explicit quality assurance mechanisms to the Waterfall model: verification is concerned…
2
I’m not sure where you read that the v-model introduced QA into software development. That statement doesn’t even make sense. What the v-model does is explicitly relate some of the different quality activities, such as acceptance testing, system testing, integration testing, and unit testing back to the upstream activities that they are connected to. Rather than “testing” being an afterthought after development and integration, quality activities are explicitly linked to up-front activities in the lifecycle. However, it also says nothing about a number of other quality activities – reviews and inspections, measurements and metrics, auditing, and reporting.
Software quality assurance is a set of activities that go into ensuring that the product being built maintains the desired level of quality by both monitoring the product as well as the processes used to produce that product. In order to monitor quality, you need to do what you are referring to as “quality control” activities – verification and validation testing – in order to obtain both quantitative and qualitative measures of process and product quality.
The assurance part comes in when this data is used to prevent problems by taking corrective action against problems, either by identifying problems early or by changing the processes to prevent problems from happening. This includes both the product and the process. For example, carrying out requirements reviews is a V&V activity, but by integrating a quality activity up front, you are being pro-active in preventing a defect from entering the product under construction. A robust quality assurance effort will also look at why defects are happening and attempt to correct them, using quality tools such as Pareto charting to identify the biggest causes of defects in work products and 5 Why Analysis to determine the root causes of them in order to apply corrective action. Beyond looking at problems, software quality assurance also addresses the things that are being done right, or the defects that are effectively finding and eliminating defects in work products or the system under development.
Another possible point of confusion might be in what organizations consider to be the role of a software quality assurance team. In my experiences, software quality assurance tends to focus more on the product quality than the process quality. At most, they might be responsible for gathering some metrics that can be used for process quality, but their primary responsibility is not on addressing how to build software, but answering the questions from V&V – was the right thing build and was the thing built right.
1