Roshni Prince asks,
Can you suggest some tips to deal with testers that attempt to dig into code and fix their own bugs?
I like the question, so I’ll tell you what I think.
If we had unlimited test time, SmartyPantsTester would rock! However, if we have to provide as much information as possible, about the current AUT quality, in a limited time, SmartyPantsTester gets in our way.
So how do we deal with SmartyPantsTester?
The Carrot Approach:
Convince SmartyPantsTester the real hero is the tester who can tell us something meaningful about the AUT quality. Can anyone help us…Please? We need someone smart enough to find the weak points in our AUT? We need someone familiar enough with the business to tell us if FeatureA will solve the user’s problems. Is anyone creative enough to determine how to test the feature the devs said was impossible to test? Is anyone methodical enough to determine the repro steps to this intermittent problem? We need someone brave enough to QA Certify this AUT for production. Get it? Appeal to the ego.
The Stick Approach:
Ask SmartyPantsTester to work extra hours until she can answer questions like the following:
- Cool, you found an incorrect join statement, how does the rest of the AUT look?
- Do the new features work properly?
- How much of the AUT have you tested?
- How many tests have you executed?
- How many showstopper bugs have you logged?
- In your opinion, is the AUT ready to ship?
And once again, I find myself with the same conclusion; there is simply too much to test in the available time. Testers reduce their chances of success by trying to do the devs’ job too.
RSS
I'll take smarty-pants any day of the week! I want him pairing with a developer, writing test code while the developer writes feature code. Then, using his superior testing skills to ferret out any additional tests needed before check-in.
Then, upon check-in, all of the automated acceptance tests he wrote earlier along with the unit and integration tests he just collaborated on would run.
Now we have time to do those deep, and expansive exploratory tests we wanted to do that we couldn't do because we were spending our time checking business logic through the UI.
If smarty-pants truly has the skills of an expert tester and decent coding chops, that should be exploited, not suppressed. Use your people in ways that will make them most effective.
Alex,
Yes, SmartyPantsTester should automate business logic and work closely with the developer. That is testing!
Roshni Prince's question and my post was directed towards testers that try to fix their own bugs (or at least tell the devs how to fix them). That is not testing.
I'm certainly not saying a tester with coding skills is a bad thing! As long as they use those skills to collect information about the quality of the AUT, they are being good testers.
I do love your post and I agree with everything you said. Although, I'm still skeptical about part of it...more later.
Smarty Pants Testers are okay as long as in the end you still find the issues and hit your deadlines.
Interesting question! I took some time to formulate my answer in the Software Alchemy blog - Who fixes the bugs?
I, like Alex, prefer the smarty-pants testers. In my post about what I think the next version of a tester should be (http://blog.theautomatedtester.co.uk/2008/07/tester-20-definition-of-agile-tester.html).
I don't think that a tester should be writing all the production code but there should not be afraid to go in and fix code if they have to.
Thanks Eric for answering my question!!
I will try to convince my tester using a combination of carrot and stick method.
Like Danny R. Faught 's article in stickymind says we can use the skills to isolate the bugs more than looking at the code and helping to fix it.