SQA & 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
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
1. Meet the requirements of user
2. Have sufficient and up to date documentation.
3. Be cost effective.
4. Be user friendly
5. Easy to learn
6. Reliable
7. Manageable
8. Maintainable
9. Be Secure
But REMEMBER!
“To every quality artifact there is an equal and opposite resisting force”
Interestingly within the same organizations quality definition changes and it becomes a nightmare for the software engineers and project managers to fulfill each user’s needs. For example the Manager wants to control the security system and don’t want any body to breach it where as the data entry operator or the accountant says; “What the hell! I am human and have made a mistake now why can’t I change my posted data with out bringing it into the notice of my bosses, I always do that when I worked manually.” See there is a clash of requirements, which is, can in longer run be treated as a quality artifact, and to resolve this, software houses need good software developers, project managers but also “The Best Analysts”.
Quality Assurance group contain among themselves some of the best analysts, who can fore see and help in removing not only the potential bugs but also can put themselves in different users’ shoes, try to work with the software as per the user’s perspective, and come up with potential problems that the software may cause with in the organization and if unfortunately the tussle would not let the software run and it would be complete loss on part of software firm. This can only be achieved if you have quality assurance group not mere testers in your organization, and the QA group is involved in all phases of SDLC.
This was a case on client end, what about quality awareness on software development end? If you visit or work in any software house you would be told that “QUALITY is our main IDEA” yet unfortunately one finds that most of these are mere lip servicing slogans and the management has only one goal “To earn Money”. Yes money is an important thing in business but it’s not the only thing. What if you earn millions in a day and due to poor quality of your product or lack of customer satisfaction you end up in loosing market for good, or in a courtroom, where you may have to repay your unsatisfied client more than what you have earned? Most importantly if any such disaster occurs it brings bad reputation to company and its employees too. This may end up in good human resources leaving the company as no one want to be a part of a bad team.
It has also been experienced quite often that in times of crunch the department or people who suffered first and the most, is the quality assurance department. This act in its self shows top management’s lack of commitment and vision towards quality. Quite interestingly it is not the case if the organization have a small testing group and no QA group. Do you know why, just because the difference between QA and testing is still jumbled in the minds and testers are given more credit than QA people who are not only good testers but also good analytics.
Reader may have also experienced that if the conflict arises between different teams / Departments, the management or Project managers are often more inclined towards developers than quality assurance group. I have even had the experience of working with some of the top IT professionals who think quality assurance or testing people are just there to prove some point otherwise the code was of very high quality and has defects which are of no importance.
This attitude towards QA and testing is also reflected in our educational institutes where during the 3 or 4 years degree program students hardly learn quality assurance courses. Even if some institute offers the course the faculty and the management fails in bringing forth the importance of this subject, the potential in the field of SQA.
So why testing is be different than QA. To test anything one need not t know or think or cater about the different analytical aspects, hence any one with domain knowledge, and software functional documents. He or she is not concerned what the actual requirements of software were. What went wrong and where and why this is not the actual client need. The only thing he / she would verify is that the software is working as per FS and if Fs is wrong it is not his / her headache. A tester can become a good QA resource if he / she has the God gifted analytical skills but this needs dedication, motivation, drive and support from the top management too. A tester needs to analyze only that specific area and how to crash the application remain within the scope.
Lets take the example of the automobile industry, interestingly the person who is driving the car for test driver is just a tester and he need not to be an expert or automobile engineer. What he / she can report or verify is that the automobile is smooth, performing well, comfortable and makes the driver happy. Now the automobile engineers who are watching the whole development cycle of the car and test drive they are the one who can get the feed back from the testers, mechanics, engineers and designers and make the recommendations for enhancing the features and quality of the machine.
Another basic difference between a tester and a QA personal is that tester is a black box for client, client may not need to know or never come to know who is the tester who is working on his / her software. Similarly for tester client is never a directly approach able interface. From experience I have learned that there should always be a QA personal included in the team, which is in direct contact with the end client. This will help in numerous ways, which I will discuss sometimes later.
Epitome:
Quality is a relative term, a variable that can vary and change its definitions according to needs, scope, culture, environment and geo-political effects.
Quality Assurance group people are not mere critics or testers; incidentally you can find the best of analysts from the QA department.
A good tester can become a brilliant QA personal but it is not possible to be an excellent QA personal without having a testing experience.
2. Have sufficient and up to date documentation.
3. Be cost effective.
4. Be user friendly
5. Easy to learn
6. Reliable
7. Manageable
8. Maintainable
9. Be Secure
But REMEMBER!
“To every quality artifact there is an equal and opposite resisting force”
Interestingly within the same organizations quality definition changes and it becomes a nightmare for the software engineers and project managers to fulfill each user’s needs. For example the Manager wants to control the security system and don’t want any body to breach it where as the data entry operator or the accountant says; “What the hell! I am human and have made a mistake now why can’t I change my posted data with out bringing it into the notice of my bosses, I always do that when I worked manually.” See there is a clash of requirements, which is, can in longer run be treated as a quality artifact, and to resolve this, software houses need good software developers, project managers but also “The Best Analysts”.
Quality Assurance group contain among themselves some of the best analysts, who can fore see and help in removing not only the potential bugs but also can put themselves in different users’ shoes, try to work with the software as per the user’s perspective, and come up with potential problems that the software may cause with in the organization and if unfortunately the tussle would not let the software run and it would be complete loss on part of software firm. This can only be achieved if you have quality assurance group not mere testers in your organization, and the QA group is involved in all phases of SDLC.
This was a case on client end, what about quality awareness on software development end? If you visit or work in any software house you would be told that “QUALITY is our main IDEA” yet unfortunately one finds that most of these are mere lip servicing slogans and the management has only one goal “To earn Money”. Yes money is an important thing in business but it’s not the only thing. What if you earn millions in a day and due to poor quality of your product or lack of customer satisfaction you end up in loosing market for good, or in a courtroom, where you may have to repay your unsatisfied client more than what you have earned? Most importantly if any such disaster occurs it brings bad reputation to company and its employees too. This may end up in good human resources leaving the company as no one want to be a part of a bad team.
It has also been experienced quite often that in times of crunch the department or people who suffered first and the most, is the quality assurance department. This act in its self shows top management’s lack of commitment and vision towards quality. Quite interestingly it is not the case if the organization have a small testing group and no QA group. Do you know why, just because the difference between QA and testing is still jumbled in the minds and testers are given more credit than QA people who are not only good testers but also good analytics.
Reader may have also experienced that if the conflict arises between different teams / Departments, the management or Project managers are often more inclined towards developers than quality assurance group. I have even had the experience of working with some of the top IT professionals who think quality assurance or testing people are just there to prove some point otherwise the code was of very high quality and has defects which are of no importance.
This attitude towards QA and testing is also reflected in our educational institutes where during the 3 or 4 years degree program students hardly learn quality assurance courses. Even if some institute offers the course the faculty and the management fails in bringing forth the importance of this subject, the potential in the field of SQA.
So why testing is be different than QA. To test anything one need not t know or think or cater about the different analytical aspects, hence any one with domain knowledge, and software functional documents. He or she is not concerned what the actual requirements of software were. What went wrong and where and why this is not the actual client need. The only thing he / she would verify is that the software is working as per FS and if Fs is wrong it is not his / her headache. A tester can become a good QA resource if he / she has the God gifted analytical skills but this needs dedication, motivation, drive and support from the top management too. A tester needs to analyze only that specific area and how to crash the application remain within the scope.
Lets take the example of the automobile industry, interestingly the person who is driving the car for test driver is just a tester and he need not to be an expert or automobile engineer. What he / she can report or verify is that the automobile is smooth, performing well, comfortable and makes the driver happy. Now the automobile engineers who are watching the whole development cycle of the car and test drive they are the one who can get the feed back from the testers, mechanics, engineers and designers and make the recommendations for enhancing the features and quality of the machine.
Another basic difference between a tester and a QA personal is that tester is a black box for client, client may not need to know or never come to know who is the tester who is working on his / her software. Similarly for tester client is never a directly approach able interface. From experience I have learned that there should always be a QA personal included in the team, which is in direct contact with the end client. This will help in numerous ways, which I will discuss sometimes later.
Epitome:
Quality is a relative term, a variable that can vary and change its definitions according to needs, scope, culture, environment and geo-political effects.
Quality Assurance group people are not mere critics or testers; incidentally you can find the best of analysts from the QA department.
A good tester can become a brilliant QA personal but it is not possible to be an excellent QA personal without having a testing experience.
No comments:
Post a Comment