Geek4Eva

There have been numerous debates on the topic of Testing v/s Quality Assurance (QA). Like: QA has bigger scope than testing, testing is more effective, QA helps find issues earlier, etc.

As per my understanding the commonly accepted argument is that ‘testing’ is something that comes at the end of the SDLC. It is the process of executing manual or automated, functional or non-functional testing. It is (mostly) conducted by specialised testers. Testers may be involved in the process from beginning, they might or might not have much input to make, but the actual testing only occurs at the end. If the development is iterative then multiple iterations of testing. But the bottom line is that testing always occurs at the end when developer passes on the piece of development to tester for testing.

Whereas QA is from the day the project is initiated. Depending on your environment, if there is lot of ‘business as usual’ (BAU) or maintenance stuff happening then I would like to say it is the on going process.

In our Applications team we believe in ‘QA’. We understand the importance of it and the advantages of implementing it. In order to achieve that the QA team recently released the new QA process where we have ‘quality control’ measures at various stages of SDLC. Various roles within the team have been given the responsibility of QA at different stages. An example of which is that Solutions Analysts (SA) are responsible to QA a Business Analyst’s (BA) work and a Developer will QA a SA’s work. As in the person next in the SDLC process QAs the work of the person before him.

Some of the advantages of QA are:

• Transperancy
• Early involvement of people
• Early feedback
• Find issues early
• Lesser cost of fixing issues
• Quicker delivery

Below is the QA process that we have come up with. It is just a high-level representation of the actual process, which is like 38 steps long. This process has inputs from the QA team, BA team, all the managers of our group and the Project Management office.