Software Development without Testers and QA
I was listening to an interview with Nik Wallenda, a tight rope walker, when he was about to cross the Grand Canyon. When asked about the issue of not having a safety net or tether, he replied something along these lines: “I have never used a safety net. If you have a safety net, then you will not treat the task with the seriousness that it requires. When you know a fall means injury or death, you make sure you don’t fall. That is how I was taught. And my father, and his father.” He comes from seven generations of tight rope walkers who were all taught to never use safety nets. (The quote is not verbatim but rather my recollection of his words.)
I thought of the parallel to software development practices that rely on the safety net of a QA department or process versus an extreme programming approach with no dedicated QA “resources”. When you don’t have a QA safety net between you and production, you are going to take quality a lot more seriously.
I consider myself lucky that my agile software training was similar to that of the tight rope walker. We had no safety net. No QA department or testers. That is not to say that we did not care about quality, we did. It was drummed into us as the highest priority of everything we did. “How do you test it? How do you test it? How do you test it?” was one of the mantras drummed into us.
During my time with this high performance team, we were deploying to live weekly with near zero bugs in production.
Now please don’t take this as disrespect for what QA people do. I have grown to appreciate the skills of software QA professionals. I find that they usually understand the product better than anyone else, ask really good questions about stories and are great at identifying edge cases. But for all of that, I am sorry, and a little scared to say in public, that I would recommend getting rid of the QA department and training your developers in extreme programming instead. Remove the safety net and train the devs to care about quality, own their product, and empower them to build processes into their development practice to ensure quality. When developers truly own and are responsible for quality (as opposed to the throw it over the wall mentality of having a tester), you will see the bug count drop to near zero.
What I notice in companies that have the QA “throw it over the wall” mentality to quality is that devs do not take ownership for their bugs. Here is a quote I heard from a dev in such an environment: “The QA team had this feature for weeks and they only find this bug now!? What is wrong with them? It’s their fault we have to hold up this release to fix something they should have found weeks ago.”
A better model than QA outside the team is moving them inside the team where QA are working alongside dev. This matches the Scrum paradigm of a cross-functional team. Especially when QA and devs start to cross train each other in skills and learn to do each other’s work. But still not the optimum in my opinion.
So what does it look like to not have QA or testers? How it is supposed to work is that the development team gets a good gut feeling for what needs testing and how best to test it. They follow the pattern described in the Agile testing pyramid. This pattern assures that the correct and appropriate amount of automated testing is happening. This includes unit tests (best created by the TDD practice), integration tests, and functional tests. This test code is a first-class citizen and will be treated with the same reverence as the application code itself. That is to say, we mercilessly refactor these and look for better ways of optimization and readability. These tests, along with the code itself, are the documentation of the product. They are a living functional specification!
The journey to a high-performing XP (eXtreme Programming) team is not quick, however, and is best trodden with a guide who has been there before you. This person is the XP coach – a role defined in eXtreme Programming. If you are ready to go down this path and begin your journey, I highly recommend you find a coach who has trodden this path to help make this transition as smooth, quick and efficient as possible.
I am excited to see that SAFe includes “Code Quality” in the framework. This is a vast improvement to Scrum, who just recommend it as a best practice, almost as an afterthought (which I have found rarely gets the attention it requires). Not saying that I like or dislike SAFe at this point. The jury is still out as it is still early days, but just saying that I am glad to see that they have taken the extreme programming engineering practices seriously.
Putting my flak jacket on and bracing for the backlash on this blog.