Making Good Software

A blog by Alberto G (Alberto Gutierrez)

Written by Alberto Gutierrez

May 2nd, 2010 at 1:18 pm

Stop waiting to the end of the project to start QA!!! (And other QA principles)

with 7 comments

Many project managers consider finding major bugs during QA an unexpected occurrence, which is like going to war hoping not to have any causalities. One consequence of such naive reasoning is that they usually schedule QA as the last stage of software development just to find that:

  • It doesn’t allow for any reaction time when major bugs are found.
  • It creates a lot of tension between QA and development. It becomes crucial for development to pass QA because they know they won’t have enough time to fix any major bugs.
  • It is not suited for exploratory testing. Exploratory testing, allows testers to have an out of the box approach to testing which is excellent to find the most important bugs of the application.
  • It requires heavy handovers and setup.

A lesson I learned quite a while ago is that QA as a separate process may work in other industries, like manufacturing, but it doesn’t work in software development. Every single unit of functionality that is coded for an application should be QA’d immediately. In particular referring to QA, these are my principles.

1.- There are no handovers between development and testing.

Coding and testing are not two separate processes, they are performed in parallel, and one can’t be completed without the other one and vice-versa. [extracted from: Continuous Integration, going beyond continuous compilation]

2.- Developers and Testers have a common goal.

They don’t perform different activities. Developers are not just focused on developing and testers in testing. They share a common goal- to produce quality software in coordination with the product owner expectations. [extracted from: Continuous Integration, going beyond continuous compilation]

3.- QA and development must provide their schedules as one unique schedule.

There isn’t one schedule for development and another for QA, and that’s because they depend on each other.

4.- The QA tester role shouldn’t be less valuable, skilled or recognized than the developer role.

I have worked in many projects where QA resources are seen as second class employees that perform easier tasks than developers. In many projects, the kind of role that is pursued is a tester that only follows a test script, taking notes on the expected and actual result for each step.

In my opinion, testers add a lot of value to the project, they should be responsible for writing automated tests, setting up stage environments and coordinate with the business making sure that they know what they expectations are.

5.- QA tester and Developer don’t need to be two different people, it is only two different roles.

Because QA used to happen at the last stage of software development, and because it was seen as a sort of certification process, management decided that QA should be part of a completely independent team, and that introduced the idea that the QA tester and the developer should always be not only two different roles, but two different people.

6.- QA should be scheduled so that I could take up to 50% of time of development.

This is just a rule of thumb, and of course it depends in a case by case basis, but is important to understand that QA is a very important task that when is completed could take up to 50% of the development time.