As the team lead for QA in a well known internet company, with prior experience in manufacturing process design, "Big 6" consulting, and a Masters in Management Information Systems, I absolutely support most of the views presented thusfar. I have worked in organizations where the QA actually produces a worse result than no QA, and others where QA really did its job, insuring the customer a solid product. The essence of the problem is not solely in development or QA; it's in the process by which both take place. Any product needs to go through a series of phases which are part of what is known as the "Software Development Life Cycle". there are many well known books on the subject which explain the concept quite well. I am particularly fond of the books by Ed Yourden. I would also recommend reading about the CMM- Capability Maturity Model.
As for developers being the best for QAing and testing their work I'll ask this: if you were an oncologist who had cancer, whould you treat yourself? If so, you have a quack of a doctor. If you were a lawyer on trial, would you represent yourself? If so, than you have a fool for a client.
By the same token, QA is by no means the answer to all problems. QA usually only has the perspective of functionality- not use-ability. Because most QA is done in comparission to the product requirements, they probably don't have the deapth of understandiong that programmers do.
On my team, I would prefer to cross train all personnel in several areas so that we can have the appreciation of those areas and be better testers.
OK, I've droned on long enough. Thanks for reading.
michael.
Slashdot Mirror
As the team lead for QA in a well known internet company, with prior experience in manufacturing process design, "Big 6" consulting, and a Masters in Management Information Systems, I absolutely support most of the views presented thusfar. I have worked in organizations where the QA actually produces a worse result than no QA, and others where QA really did its job, insuring the customer a solid product. The essence of the problem is not solely in development or QA; it's in the process by which both take place. Any product needs to go through a series of phases which are part of what is known as the "Software Development Life Cycle". there are many well known books on the subject which explain the concept quite well. I am particularly fond of the books by Ed Yourden. I would also recommend reading about the CMM- Capability Maturity Model. As for developers being the best for QAing and testing their work I'll ask this: if you were an oncologist who had cancer, whould you treat yourself? If so, you have a quack of a doctor. If you were a lawyer on trial, would you represent yourself? If so, than you have a fool for a client. By the same token, QA is by no means the answer to all problems. QA usually only has the perspective of functionality- not use-ability. Because most QA is done in comparission to the product requirements, they probably don't have the deapth of understandiong that programmers do. On my team, I would prefer to cross train all personnel in several areas so that we can have the appreciation of those areas and be better testers. OK, I've droned on long enough. Thanks for reading. michael.