Last year I started working on a small team with developers that really value testing and treat it as in integral part of the development cycle. I’ll never forget one of our first planning meetings when we were discussing a feature that we were about to build and a developer frowned and said “Yeah, but how are we going to test it?”. As a result they changed the whole design.
I think I just about fainted with shock, having never heard that in my career. The key part of this was that it wasn’t the team asking me, the tester, how *I* was going to test it. It was a question asked of the whole team – how are we as a team going to test it? How can we build this so that we have confidence that it will work as we build it?
As we built features, the developers would always write tests – everything from unit tests to browser level tests – and have another developer do some manual testing before it was passed to me for testing in a fully integrated environment. By the time it was handed to me this way, I rarely found bugs that were due to carelessness. Most of the bugs I found were due to user scenarios or system scenarios that hadn’t been thought of earlier.
So you might think, as a tester, did I really have much to do on a team like this? My most valuable asset in this process was still the way I thought about the product – from a testing standpoint, from a user standpoint. What I found was that my testing expertise became less valuable at the end of the cycle and much more valuable at the start. The more effort I put into testing the product conceptually at the start of the process, the less I effort I had to put into manually testing the product at the end because less bugs would emerge as a result.
I just want to break that last bit out into a big fancy font quote here because I think it’s quite important.
The more effort I put into testing the product conceptually at the start of the process, the less I effort I had to put into manually testing the product at the end
But the key part of this was that I knew that the development team was testing the product effectively by thinking about testing, writing tests and manually testing as the product was being developed. I could trust that if we had thought of a scenario during planning, it would be effectively developed and tested with automated regression tests in place by the end of the process.
I’ve had a lot of discussions this year around the role of the tester. Let’s put that aside from now and start thinking about the role of a software developer. A software developer needs to be able build a product with confidence that it does what it’s expected to do. Knowing how to do that at a basic level should be critical to the role of a good software developer. For that reason, we need more testing in software development. And it needs to be done by the people building the product.
Having a testing specialist on the team is a valuable asset, but the role of a specialist isn’t to restrict that responsibility to a single person. You might also have a database specialist on your team, but it doesn’t mean that they’re the only person working with databases. The same goes for testing. The specialist can help with the really difficult testing problems, knowing that the rest of the team is capable of dealing with the simple testing problems.
Then it’s shorter feedback loops, greater confidence and faster quality releases for all. Who doesn’t love that?
Special thanks to Chris, Bram, Tom and the rest of the Wildfire team at Google – you guys rock.
Special shout out to Alan Page who’s made me punch the air and yell “hell yes!” every time I’ve read his blog this year.
I’ve been lucky to be on teams with developers like the ones you work with now for most of the past 13 years. I’ve tried hard to explain to people what this “whole team” ownership of quality and responsibility for testing really means. You found the perfect way to say it. Let’s hope there will continue to be more and more teams with this attitude!
If you have full of testers in ur team, then how many times u r going to redesign. Is that really feasible. If in one instance is true then it is not necessarily required to be true in all
Great post! I have started my rant about this topic too!
I did a talk called “Stop treating testers as failed developers when developers are failed testers”. Feedback was good and didn’t piss people off too much
The process you describe is QA as in assuring quality, which is only possible by designing quality right into the product. If that is done properly and consistently the QC portion where quality is controlled is easy, much faster to do, and not hampered by fundamental bugs that take focus off what really matters.
Now we have to find out how to get this approach into every software shop. The world would be a better place!
I liked this, and liked it a lot. Especially the parts about the early involvement of testers being the most important. At that point, we are validating the design – if it doesn’t work on paper, then how are we going to test working functionality into the end delivery.
You can’t test quality in, it has to be baked in – almost a quote [but not quite, as I am not up to diligently searching for it ……….] from the Lisa Crispin / Janet Gregory book. But I do give the credit …………
Loved the way you explained it! And of course I absolutely agree :)
Great post Trish.
Agree with everything you say, but don’t understand the title.
If it’s about testers being involved at the start of the process: shouldn’t it be “we need testers in analysis”?
Thanks Alister. The title was referencing the job title “developer in test” which is often a tester who has development skills. So, turning that around, I was saying we need “testers in development” meaning a developer with testing skills.
It is a good artical, As you said the testers early involvement in the project should be grate value and delivering better quality product to customer. In agile process, the test team involved from start to end of the product(set of modules). Testing the application with automated tools are value to product quality.