Quality Assurance Is Not Responsible For Quality
Quality Assurance Is Not Responsible For QualityQ. Here is a scenario, assuming you are hired for a small software company as QA Engineer where there is no smell of QA (well, little bit) and you are responsible to setup QA infrastructure/process, testing and quality of the entire product.
A. There is no way to take this responsibility. This is a classic trap that QA people get caught up with. You can't assure quality. Drop the QA label, and tell the developers that they are responsible for the quality of their own work. Offer to help with testing only (quality assessment). And don't form a test department. It's not agile and as soon as the 15 developers learn that there is a test department, they will all slack off on their testing.
You are successful if:
Now this is the kind of bravado I like to see... -- JasonYip
This seems to reflect what Philip Crosby wrote in QualityIsFree. It also raises the question, what is Quality Assurance responsible for?
Some thoughts: Source of best practice and advice on how to measure (and in some domains) achieve quality, and how to design metrics and measures. For instance, in manufacturing, would be the center of expertise on statistical process control. Maintainer of documents, records, processes etc. Supports audits to external standards (e.g. ISO9000, BS7799).
Hmm. "Measuring quality" -- this sounds like testing to me, or else humbug metrics intiatives. "Achieving quality" -- I would love to see a Quality Assurance department staff with experienced developers who could coach the team write better code. But i've never seen it. Instead QA staff tend to be "process" people. Statistical process control is a great idea, but i am tired of hearing about it in software. The problem is that it only works with processes that are sufficiently well defined and unvarying that they can be analyzed in terms of statistical process control. Most of software development isn't. Too bad. Maybe it could be used to analyze build failures... "Maintainer of documents, records" -- Sounds like a librarian. Maybe librarians should start calling themselves QA because the maintain the quality of our civilization. The question really is why should these many activities, while sometimes useful, be labelled quality assurance? It sounds pretentious. Kind of like a garbage man calling himself a sanitation engineer. -- BretPettichord
QualityAssurance is the police & judiciary of Quality. They are there to be independent of the commercial pressures of the project, but to ensure that whatever quality measures that were agreed are actually carried out.
Maintaining documents, keeping records and performing audits are symptoms of this happening.
In short, the QA department can't create quality. At best, they can detect lack of quality and prevent low-quality products from going out the door.
That's quality control, in my book. I think QualityAssurance goes further. I think the difference is like that between external auditors and the internal audit function - external auditors check your accounts and so on are sound, that there's no (obvious :-) fraud etc. Internal auditors work with management to implement controls to ensure that that remains true (another example might be external security testing companies versus a good internal security function). So a good QualityAssurance function should be able to work with your design and production people to assist in designing systems that do produce quality outputs
Uh... I don't see people dropping the QA label here... and you're all still referring to separate QA departments...
Maybe we don't agree that it should be dropped?
I would agree with eliminating current QA departments and placing the responsibility for quality on to the developers. There is a place for a separate department to review, improve, and replace development processes, but this would be far closer to "Computer Science" than anything that current QA departments do.
SoftwareEngineering, rather. And I think that rather assumes that overall product or service quality is merely a matter of quality software development, which is questionable unless you're just running a software development company (and still questionable even then).
Sorry, I did not intend to imply that "overall .. quality is merely a matter of quality software development." I only intended to imply that quality software development is best handled directly by the developers and improvements in software development do not come out of QA organizations. I fully agree that there are other things affect overall quality beyond software development.
See WholeTeam
I found an interesting aspect of the CleanroomSoftwareEngineering to be that it explicitly makes quality the responsibility of the developers. The CleanroomSoftwareEngineering also requires having an external testing group. The testing group's function is NOT to "find all the bugs." The testing group's function is to use the system much like real users would, and to provide feedback to the developers, via metrics, to tell the developers if they've achieved the desired level of quality.
The CleanroomSoftwareEngineering isn't for everyone. (I've never tried it.) But I think their perspective on what an external testing group should do is interesting. -- JeffGrigg
For the record: I am not against having test teams. I sometimes recommend them, although I did not in the scenario that spawned this page. I am however, almost always against "quality assurance" teams. I have seen useful teams with this label in a few occasions. And in these cases, there was a separate testing team. A test team with a "QA" label can easily get confused about how they can be most helpful. -- BretPettichord
QualityAssurance is not for testing, in my opinion -- that is without a doubt the developer's job. But the tests cannot possibly cover every condition in which the system can be used, especially in a system such as ours with many complex interactions, multiple modes and strict compatibility requirements with differing versions of other software. Someone has to go out and bang on the system for a while, exposing the weak points that weren't anticipated when the tests were written. This is what the QA team is needed for -- they know how to thwack the system to find the bugs in it that haven't been tested for. Then they work out how to replicate the bugs and submit bug reports to the developers, who can fix the bugs and add relevant UnitTests to make sure the bugs don't show up again. -- RickSamuels
This may be my own personal bias, but I have always been troubled by the assumption that an external test team knows more about what the product needs to do than the developers. Why should we expect the QA team to "know how to thwack the system" if the design team did not know how to build the system? This seems to be a process to ensure developer mistakes. -- WayneMack
I think knowing more isn't the issue. Comparing "more" serves only to boost the egos of the "experts". The question is how to assure the quality of the software, and knowing more isn't necessarily paramount to accomplishing that goal. In fact, knowing less about the system can facilitate very effective testing. New users can readily take a fresh look at the UI and identify areas that are flawed or unintuitive. During the process of learning the software a user explores the UI and will likely go down paths that an experienced user will not. These exploratory paths are much more likely to find defects.
The developer will naturally tend towards the "ideal" way the user will use the software. Consequently the developer will (usually? hopefully?) do a good job of testing what they perceive as the normal usage of the software. QA can test outside the path the developer will gravitate to and facilitate end-user review to identify and test new paths through the software, eliciting usability information along the way. The QA person can add value by having the skill to recognize what is happening in ways that the end-user cannot see or articulate and presenting that information to the developer in an actionable form.
In projects where the development team is behind, which is to say nearly every project, developers tend to become more defensive, advocating the schedule and focusing on survival. QA can serve as a useful counterbalance advocating the true customer needs and measuring consequences of developer decisions in terms of business value. Developers won't have the time or perspective to perform these activities effectively.
Before any attacks me for targeting these remarks towards developers, let me clarify. First off, I AM a developer, currently working as QA on a project. My point isn't that developers aren't capable of performing these tasks, it's simply a matter of role and perspective. When you're working on implementation you have a drastically different view of the project than when you are doing QA.
Let me try to express my argument in a different way. I am arguing in favor of having informed developers. It is not up to the developers to determine the "ideal" way to use the software; the developers need to implement what the users require. Having QA (I am using the term here in the context of "Independent Testers") know less about what the users require is not an advantage; it means their effort is most likely to be misdirected. The result is the set of problems reported by Independent Test have no relationship to the problems eventually found in the field. This keeps bringing me back to the oft repeated homily, "You can't test quality into a product." It is certainly debatable whether Independent Test provides value, as software development is currently done. The direction for improvement needs to be, however, focussed on improving the development side and eliminating the Independent Test side. I must also note that this line of thinking has been highly influenced by WilliamEdwardsDeming, although he never directly addressed software development. -- WayneMack
"the developers need to implement what the users require" That is a key part of the equation. What you are saying makes sense as an abstract argument, the people factor here is what determines what is necessary. My experience is that many developers don't have the ability or desire to communicate directly with the customer and find out what the customer needs. I've seen a requirements analyst do a good job of documenting customer requirements and the developer not even reading them. I've also seen a developer read the requirements and assume they are correct and complete when that was not the case. In this sort of situation dedicated QA can perform a useful role if they have the skills to work closely with the customer. Saying the developers need to improve is certainly true. Given that many have not realized or attempted that improvement makes a strong case for the QA role on such projects. What we can certainly agree on is the QA tasks need to be performed. Who will fulfill them and what the title of their role will be remains a question of the people available and their skill sets.
The job of the QualityAssurance team, in many organizations, is to be laid off first when the axeman cometh. Many managers I have known are hesitant to hire "QA" engineers (or designate anyone with that title) for that very reason; when downsizing comes, they are regarded as expendable. Sad, but true.
Of course, in many modern production models, ex-post-facto testing is seen as overhead to be eliminated; this is one of the premises of QualityIsFree and the like--it's better to eliminate the defects up front rather than require extensive and expensive testing of the end product. Trouble is, when SWQA teams get the axe; little if anything is done to improve the quality of the design engineers' work (other than management edicts to WriteBetterCode?, edits which usually have no substance behind them). For elimination of the QA function to be cost-effective, it must be truly redundant--eliminating a QA team that is very prolific in defect-finding is not a good idea.
-- ScottJohnson
Actually Philip Crosby in QualityIsFree insisted on having independent test as part of QA. Perhaps you are thinking of WilliamEdwardsDeming who said "Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place." (point 3 of his FourteenPoints). Dr. Deming, however, also provided economic guidelines as to whether a system should be in a final inspection mode or not. -- WayneMack
We will have to look the whole development process from both the side. From the developer point of view and from the customer point. It is the developer who is involved in the project and developing the code. From the situation where he is in, he might not expect the end user to behave in the manner they shouldn't. The process that the customer will follow will resemble the way he is working. In the real world this happens almost 80% of the cases. So, he is almost correct from where he is. From the end user perspective and depending on the environment, the mood swings there are equal chances he can do anything silly which he also regrets later. What he would expect that the software should be able to behave satisfactorily after the mistake that he had done. So, the importane of QA or QC cannot be ignored as when the build is made available to the QC team they tend to use the software the way any ordinary person would do.
Rupesh
EditText of this page
(last edited January 2, 2010)
or FindPage with title or text search