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.