While going through some of the software QA related stuff, I found a very nice presentation done by Michael Bolton. There, he challenged the traditional way of defining software quality assurance teams. While agreeing with his insight on QA, I thought to highlight the contents included in one slide of his presentation.
If you are involved in software quality assurance (or if you think that you are a software QA person) then the following will be able to help you to get yourself categorized into the correct role that you are playing in your organization.
- design the product?
- hire programmers?
- decide which bugs to fix?
- allocate staff?
- set the schedule?
- fix problems in code?
- decide on raises?
- allocate training budgets?
- produce manuals?
- choose the development model?
- fire some programmers?
- control the budget?
- set the company's strategic direction?
If the answer for all of the above questions is , YES, then you assure the quality of the products produced by your organization. So you are doing software QA!
I have never found a QA/testing team who performs all of the above activities in their job. But most of us test the products. We explore the products in order to reveal the issues and provide feedback to the stakeholders of the product under development. Therefore our role is Software testing NOT quality assurance.
James Bach defines software testing as questioning the product in order to evaluate it.
Cem Kaner says software testing is a technical, empirical investigation of a product, done on behalf of stakeholders, with the intention of revealing quality-related information of the kind that they seek.
So, there is no assurance!