Don't Fire QA - Embed QA in to Agile teams

Mike Gualtieri recently wrote a post about how 1 financial data company was able to improve software quality by firing their QA team and making developers responsible for testing the software. This is a good concept - have the team of engineers responsible for creating the software also be responsible for proving the software works. I agree that you should break down the barrier between a development team and a QA team. I disagree that you should fire your testers. You should Embed them in to Agile teams.

I met with a client today who described doing weekly releases to a very high volume online advertising system. This system has hundreds of servers around the globe and is directly revenue generating software with complex algorithms. His approach was not to fire the QA but to embed them in to the development scrum teams to help the developers make even better software.

This is one of the basic tenets of typical Agile software development approaches. To quote Janet Gregory, Agile teams have "Blurred Lines Between Roles":

• Agile developers are "test infected"
• Agile testers and programmers collaborate
• Agile testers and customers collaborate
• "Whole Team" responsibility for testing
• Everyone understands the business

When you follow these approaches, you get Unit tests from your developers. You get acceptance tests written for user stories BEFORE the code is written. You get developers who try to prove their code works, not who just try the happy path and throw the code over the wall to QA and wait to see what bugs get reported back.

When you have developers who are responsible for executing regression tests, you get automated unit and regression tests to validate the software in every build. And when you have developers who are responsible for successfully deploying the software to production they think about how to automate the deployment so it works every time. This is all good!

But you still need people who are trained to think about testing, requirements, and user story completeness, and who are used to looking for corner cases, and thinking like a user, and who have seen bad data, funny encodings, and the hundred other oddities that a skilled tester can find in software.

This is why it's better to embed the QA testers in to the scrum teams. The TEAM is responsible for the software quality. The 1 or 2 engineers on the team with a QA background go about ensuring quality differently - they work with the users and customers more to ensure the team really understands how the system is going to be used. They build automated tests for parts of the system that are not easy to automate with unit tests. They double check the consistency of the look & feel. They run stress tests. They manage sample data. They ensure that 2 user stories do not conflict with each other. They do all the things that a developer focused on a single user story might miss or not realize was important, because after all the developer's code passed the unit test and passed the acceptance tests.

If you want great software, you need more than just coders. You need testers - but you need Agile testers who are part of the software creation process, not a separate team given an impossible task of "finding all the bugs" in code casually written by the coders. Don't fire, EMBED QA!