the future of software testing (part 6)
Testing Culture
A couple of months ago I attended a lecture given by one of the Empire’s cache of Technical Fellows (maybe he was a Distinguished Engineer, I am not sure as they look so much alike). Like all our TFs the guy was wicked smart and as he presented a design for some new product he and his team were building I had an epiphany.
Evidently epiphanies cause me to display facial expressions akin to one who is passing a kidney stone. The TF noticed (so did the gal sitting next to me, but I don’t want to talk about that) and approached me after the talk. Here’s how that conversation went:
“James,” (he knew my name!) “you seem to have some issue with my design or with the product. I’d love to get your feedback.”
“No, I have no problem with either your product or with your design. My problem is with you.”
“Excuse me?”
“People like you scare me,” I told him. “You spend all your time dreaming about features and enabling scenarios and designing interfaces and protocols. You are in a position of importance and people listen to you and build the stuff you dream about. And you do all this without knowing squat about testing.”
And this was the moment he sought to do the right thing … reach out to test. He invited me review the design get involved. It’s exactly what you’d expect him to do.
But it is exactly the wrong response.
Having a tester involved in design is better than not having test represented at all. But not much better. Testers will be looking for testability issues. Developers will be looking for implementation issues. Who will be looking at both? Who will be able to decide on the right tradeoff? Neither. Getting testers involved in design is only incremental improvement; getting designers (and every other role) involved in test is the future.
Seriously, how is it that the people who build software understand so little about testing? And why have we not tried to fix this before? Are we, as testers, so vested in our current role that we are jealously guarding the keys to our intellectual kingdom? Is testing so arcane and obscure that developers can’t find the answers they seek? Have developers grown so accustomed to handing off this ‘less interesting’ aspect of the process to us that they now take it for granted?
Adding testers to the mix hasn’t worked. Getting them involved earlier hasn’t worked. We have products that have a 1:1 ratio of developers to testers and yet those products are not seen as highly reliable. We also have products that have far ‘worse’ ratio that are clearly better products. I think in the future we will come to see that the separation of roles isn’t working. The separation of roles might even guarantee that testing comes late to the dance and fails to fully leverage its intellectual potential on the product.
The current testing culture and separation of roles is broken and the way to fix it is by merging roles. Quality needs to be everyone’s job. Think of it in Tolkiensian terms: one role to rule them all!
Imagine a world where testing knowledge is contained in each and every contributor’s head. The architects know testing, the designers know testing, the developers know testing and they apply that knowledge constantly and consistently in everything they do. This doesn’t wipe out the separate testing role, there is something to be said for some amount of test independence, it enables better testing. If each decision made throughout product development asks the right testing questions, then the final system test can reach a level of thoroughness we can only dream about now. If everyone on the project understood testing, imagine what a few dedicated testers could accomplish!
Getting to this testing utopia is going to require a massive cultural change. Testing must reach into academia and the other places where programming is taught. As developers progress in their careers, this education must continue and become more advanced and powerful. We need to get to the point that all project stakeholders understand testing and can’t help but to apply its principles in everything they do. Tools will one day support this as well. One day we will be to the point that untestable software just never gets written, not because some strong tester made it happen, but because everyone on the project made it happen.
Testing is too important to be the ‘bit at the end’ of the process. It is early in the process where design decisions impact testing and it is there that the solutions lay. It's also too important to leave it in the hands of a single role dedicated to quality assurance. Instead we need a fundamental cultural shift that makes quality everyone’s job and embeds its principles in everything we do.
Comments
Anonymous
September 24, 2008
PingBack from http://hoursfunnywallpaper.cn/?p=7661Anonymous
September 25, 2008
Ajoyk on New Agile Process Template for Team System from NetObjectives Michael Freidgeim on My Experience...Anonymous
October 03, 2008
Boy! Did this post ring a bell or what?!! I am constantly surprised by how little even some of the most successful developers and PMs know about testing. Its not that these guys are not smart enough to understand, its just that they choose to ignore it. Ignore something that affects the product in such a fundamental way! The cultural change you talk about effecting is a HUGE and direly necessary one. I am really looking forward to hearing more from you about how you think we can actually start bringing in this change. Great post! :)Anonymous
October 04, 2008
I agree with your points and have found some of the best code (in terms of speed to market and quality of the release) where I work comes from developers who simply will not let their code be untested. They will ensure their code is well tested, either with - or without - the involvement of the 'testers'. As you might imagine, they are a pleasure to work with :)Anonymous
October 18, 2008
The comment has been removedAnonymous
February 03, 2009
[Nacsa Sándor, 2009. január 13. – február 3.]  A minőségbiztosítás kérdésköre szinte alig ismertAnonymous
February 08, 2009
[ Nacsa Sándor , 2009. február 6.] Ez a Team System változat a webalkalmazások és –szolgáltatások teszteléséhez