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.

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

Subscribe to comments with RSS or TrackBack to 'Stop waiting to the end of the project to start QA!!! (And other QA principles)'.

  1. […] This post was mentioned on Twitter by Rui Curado, Manuel. Manuel said: GR> Stop waiting to the end of the project to start QA!!! (And other QA principles): Many project managers conside… […]

  2. Your fifth tip is the best one !
    Many developers thinks that Tester and Developer must be two different people in two different area.

    I believe that the best person to test some routine is the one who create them.


    3 May 10 at 3:29 am

  3. Hi Alberto,
    I’ve translated in french your excellent post : Cessez d’attendre la fin du projet pour commencer la recette technique
    Regards, Fabrice

    Fabrice Aimetti

    3 May 10 at 4:02 am

  4. Great tips, though I don’t agree much with the fifth one. Of course you have to test what you’ve developed, but you are not the best person to do it as a final test. Sometimes you are very used to the code and can miss some scenarios. That’s why I think it is important to test your own code, but it is best if someone else test it to give you a second opinion.


    4 May 10 at 9:51 am

  5. #4 should actually be #1. People don’t give enough credit to QA, and because of that not enough talented individuals are driven to the position.

    #5 is flat out rubbish. As one of the other comments noted, a developer should *absolutely* test their own code as their developing it (duh), but it should be passed off to a QA team for final testing.

    When you build something to a certain spec, you tend to verify functionality within that spec, but you’re often so immersed in the spec and the building of the feature/functionality that you forget to see what happens when certain actions outside that spec are performed. That’s where QA comes in and runs through a standard suite of tests (both automated and human) and basically just tries beating on random things with a baseball bat. A developer is simply not going to find all the more random and obscure bugs within their own code.

    It should be noted, however, that once something has been identified, the developer is of course very likely to have an “Oh! I know what that is” moment.

    #3 is also not entirely accurate in my opinion. If you’ve got a QA team and a team of developers constantly interacting with one another, it’s likely close to nothing will get done. At the end of a project it makes sense to work closely with a lot of back and forth, when wrapping up final small bugs, design tweaks, etc. However, earlier on in the QA process, while there is still active development going on and larger functional bugs to be fixed, the developers quite frankly “need their space” and they need time to focus on these somewhat larger tasks. If the QA team is constantly bombarding them with new tickets, questions, etc. it can become difficult to focus.

    Finally, that brings me to the main point of the article. It should be clarified that (at least I hope this is what the author meant) while QA should not wait until the very end of the project, it should also not start too early. If you have a QA team pounding away at a half-finished product, they’re almost guaranteed to start reporting “bugs” which in reality are simply features which aren’t finished yet or something a developer is not only aware of, but actively working on as part of the ongoing or earlier stages of development.

    Mark Rebec

    4 May 10 at 5:21 pm

  6. I like your principles. Like some of the other comments have addressed, the 5th tip needs to be qualified.

    A developer obviously knows their code intimately and probably knows about certain issues that may come up. However, it’s difficult to change perspective from designing and building software you are proud of… to trying to break the software that you wrote.

    It’s along the same lines of why a writer needs an editor or proofreader…

    Raymond Li

    6 May 10 at 6:36 am

  7. […] Stop waiting to the end of the project to start QA!!! (And other QA principles) – Alberto Gutierrez (Making Good Software); […]

Leave a Reply