When programmers log bugs, us testers are grateful of course. But when programmer-logged bugs travel down their normal work flow and fall into our laps to verify, we’re sometimes befuddled…
”Hey! Where are the repro steps? How can I simulate that the toolbar container being supplied is not found in the collection of merged toolbars?”
I used to insist that every bug fix be tested by a tester. No exceptions! Some of these programmer-logged bugs were so technical, I had to hold the programmer’s hand through my entire test and test it the same way the programmer already tested it. This is bad because my test would not find out anything new. Later I realized I’m not only wasting the programmer’s time, I’m also wasting my time; from other new tests I could be executing.
Sometimes, it’s still good to waste time for the sake of understanding but don’t make it a hard and fast rule for everything. Instead, you may want to do as follows:
- Ask the programmer how they fixed it and tested their fix. Does it sound reasonable?
- Ensure the critical regression tests will be run in the patched module, before production deployment.
Then rubber stamp the bug and spend your time where you can be more helpful.
Had the same problem. After way too long pulling hair out trying to get tickets that made any sense from programmers, we just stopped testing them. Instead we made sure to do regression on the parts of the software that their bug fixes affected. Luckily we tracked the modules they fixed in our ticketing system, so it made our job a bit easier.