Jonathan Howell

I was disturbed recently to hear that a major internet company is planning to move their entire QA operation to India. I’m not against offshore development done right (I have seen in done well, badly and terribly in my time), but this is not about offshore development: the development team remain firmly in London. This is a change to QA from being on the other side of the building from development (bad enough) to a continent and several time zones away. This is craziness, especially for a company trying to embrace agile software development.

At the core of agile development is the delivery of small increments of production ready code that have meaning to the customer. Each of these user stories is not considered done until it has been coded, tested, any necessary documentation written, refactoring done, and the customer has approved it. It is in fact this incremental approach that makes agile development agile. When you are 6 weeks in to a 3 month waterfall project, you have a fully written spec and some half written code, none of which is tested. That doesn’t give you much scope to change your mind on anything: changing the scope is hard work because the final requirements document is the one thing that you *have* delivered. And if you cut the project short after 6 weeks you have delivered precisely nothing of any use. With agile, 6 weeks in to the project you will have produced the highest priority 50% of your original requirements to production quality, and could stop the project there if you wanted to (subject to the overhead of a release of course). Or the requirements for the second half of the stories can be updated to reflect real user feedback from the stories delivered so far. For me this is the essence of agile, and why organisations that continue to do waterfall, but chop up the development phase in to two week iterations and think they are “doing agile” are completely missing the point. As are organisations that think testing is something that starts once development is finished.

In my experience, here is what happens when QA testing is a phase that starts when development have finished, and is executed by a team that don’t sit alongside the development team (on a different floor or across the world). The development team write code for a month or so. They don’t really care about whether it works or not because that’s QA’s job, and anyway, they are under pressure to hit “code complete” on time not to produce production quality code. The release then gets thrown over the wall to QA, who run it, say it’s junk and then throw it back again. After this has happened for a couple of days, there is a kind of workable version of the application to test, and QA test and raise loads of bugs. Developers then reject them all. And QA reopen them. And developers say it must be an environmental issue as “it works on my machine”. This conversations is of course happening via comments on the bug tracking system with each side fuming at their keyboard at the incompetence of the other. They are on different sides after all, and never actually speak to each other. In the end it turns out that QA had written a bunch of test cases in isolation from the developers writing the code, and both had a slightly different interpretation of the requirements specification, and both think that they are right. An exaggeration? Well, maybe, but I am sure you recognise bits of this.

Agile testing is an integral part of development, and QA work alongside developers to produce quality code. They are on the same side and are jointly responsible a quality and timely delivery. Misunderstandings of the requirements are resolved by an actual face to face conversation (including the on-site customer as necessary), and this conversation happens well before the code is finished - preferably before it is even started. Of course, developers and QA analysts are coming at it from slightly different angles (which is why both are necessary in the team). Developers like creating things of beauty, and once created don’t like poking them too hard in case they fall over. They like thinking of exciting ways what they have written could be used or reused, not of ways that someone may break it by doing something they didn’t expect. QA analysts on the other hand are good at exactly that: analysing all possible paths through the functionality, not just the “happy path”, and defining test cases that will ensure a quality product hits production.

Integrated testing is a fundamental part of agile, and QA belongs in the development team, and in the iteration. Moving QA to a different time zone to the developers is simply not compatible with this.

This entry was posted on Saturday, March 7th, 2009 at 11:19 am and is filed under Agile. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.