Quality Assurance & Testing ”Some Myths”

Quality Assurance is comparatively new phenomenon as to testing. I would like here to be specific while defining quality, its assurance and differences from traditional testing methodologies.

Glance at Software Industry and Quality artifacts:

Unlike the industrial revolution in “West” software revolution didn’t take centuries to sow the seed and then boom with a vertical graph, instead it took the software industry less almost half a century to evolve, flourish, and experience the crests and troughs. Quite rightly this is the offspring of baby boomers generation, post world war scenarios, super powers’ marathon, and industrial revolution.

Although the software industry learned fast but still the path it followed was same as was taken by its predecessor industries. While saying that I mean look at the traditional industry, it took them centuries to understand and digest the need of quality product and satisfied customer. Similarly software industry started without having any knowledge of the customer’s exact needs, without any framework, without any diversified targets.

I think many of the readers would agree with me if I say that software industry had the sole aim of superiority of weapons, in its infant days. Fact of the mater is the today’s software industry owes a lot to the “Department of Defence” (DoD) and its subsidiaries. All the buzzwords we utter today like CMM, Malcom Baldrige (MBNQA), and SPICE are the product and requirement of DoD.

To stream line the process of its software manufacturing, and outsourcing, DoD came up with these different sorts of parameters, standards, and tools to measure where the organization stands which intend to do business with DoD by providing the solution towards the software needs of DoD.

But still do you know what is quality? How and why would different people and organizations have different set of processes and standards? If they all don’t have the same framework then who is performing the actual quality work and how can we categorize them.

To deduce the actual trend and definition of quality lets discuss a few examples. For NASA software’s reliability, and performance matters most. For Mr. X software is good enough if it looks good, GUIs are aesthetic; performance and reliability are secondary issues for him in the initial stage. Hence for two different customers primary and secondary issues swap. Same is the case with the quality of these soft wares, if NASA’s software is not very aesthetic in look and feel but it performs excellently with accuracy and is 100% reliable they would say it is of high quality whereas if Mr. X is made to use a very reliable but difficult to use software with crude interfaces, he would definitely going to resist. For Mr. X the quality parameters are not the same as for NASA.

So we conclude that quality is a relative term and it is a variable, which keeps on changing. That’s why I keep on saying “Quality lies in the eyes of beholder”.

Now if we try to define a few major quality artifacts we would have a checklist that would look some thing like this:

Quality software must

ü  Meet the requirements of user

ü  Have sufficient and up to date documentation.

ü  Be cost effective.

ü  Be user friendly

ü  Easy to learn

ü  Reliable

ü  Manageable

ü  Maintainable

ü  Be Secure

But REMEMBER!

“To every quality artifact there is an equal and opposite resisting force”