How do you perceive quality assurance? Back when I was evangelizing QA in my previous job, I often used the question “What do you think of when you hear the term QA?” to jump-start introductory presentations. When speaking to developers I would almost invariably get the following response: “They are there to test my product”.
So isn’t it just testing?!
This perception of QA and QA people is very narrow and misguided; classic Quality Assurance is made up of three widening circles of responsibility:
- Software Testing: this is where the product testing is done. This is what most developers think of when they hear the term QA.
- Quality Control: this is where the product’s actual quality is quantified and managed through test planning, test environment and execution planning, defect measurements and more. One of the QC activities is software testing.
- Quality Assurance: this is where the product’s development quality is monitored and (hopefully) iteratively improved in order to assure it will product a quality product. This includes monitoring the product through testing and measuring it (in other words, QC), and also monitoring the product’s development processes.
Process improvement through QA?
Yes. Quality Assurance literaly means making sure we develop a quality product. It does not mean only testing that the product we made is of high quality; at this stage it may already be too late.
If the development processes is in disarray, corners are being cut, assumptions being made etc., the end product will most probably be of low quality, and you don’t need to wait until a host of testers take over it to get the news. Making sure the QA process is methodical, correct (i.e. answers the customer’s requirements) and often reviewed, helps get a more mature product to the testing phase.
A call to arms
One way I know of (which deeply impressed me) to get development done in a highly methodical, self-reviewing and highly measurable way is TDD: everything is tested well before it’s out of development, everything is requirements-driven and by utilizing an automated build you can get a very quick indication the moment a mistake is made; the process is practically self maintaining.
QA engineers, leads and managers, this is a shout out to you. Do you want to improve the product quality and get outside the “you’re there to test the product” box some developers place you in? You can promote implementation of TDD and unit testing in your organization. It will be good for the development process. It would even be good for your (or your employees’) personal development as it expands your horizons into the world of development practices and coding skills.
So, are you going to pick up the gauntlet? Want to get started and don’t know how? Discuss it in the comments or in our forums!
Technorati Tags:
QA , Quality Assurance , mock, Software Testing,Software , Net Development , Asp.net , C# , Agile ,Test Driven Development , Mock
