A developer I don't work with often made a change, tested it against the
problem case that motivated it, and then asked me to have a look.
I started by reading his description of the testing he'd done, reviewed his commits, and then ran the application with and without the change.
After testing for a short while I went back to him having found a major
problem.
This isn't a blog post slagging off how developers (don't) test, it's also not about how testers should strive to create a quality culture and coach the team, and it's not about how clever I was at finding the problem either.
This blog post is about the response the developer gave when he heard my report: "what made you think to test it that way?"
Which is a great question from someone who wants to improve themselves and their work. I didn't want to put him off ever asking me anything ever again by taking the opportunity of an apparently receptive audience to lard on the testing know-how. So I said something along these lines:
There are basically two sides to testing a fix like this, and you need to look at both:
- checking for the intended effect
- looking for unintended consequences
When I'm testing I will often try to find ways of cheaply giving myself a chance to see unintended side-effects. In this case, it was to force the fix to be exercised lots of times on very little data. This makes the outcome easy to scan and problems easier to see, for example wrong results or missing application of the fix.
It is easy to be indignant or critical when finding a problem quickly, but I do know that when developing it's easy to skip or lightly touch the looking for unintended consequences. Hell, just last week I committed changes I didn't mean to because I
didn't look first, unjustifiably confident in my shallow checks, keen to
capture the good work I'd done.
So while this is a blog post about the developer's excellent attitude (and I told him I thought it was excellent) I'll slip in a note-to-self too: remember to have empathy for the person whose work I'm looking at. Yes, I found an
issue here but there's other sides to every situation.
Image: https://flic.kr/p/71nsew
Image: https://flic.kr/p/71nsew
Comments
"What programmers do poorly is discovering overlooked special cases (especially error cases), bugs due to the interaction of their code with other people's code (including system-wide properties like deadlocks and performance problems), and usability problems."
http://www.exampler.com/testing-com/writings/classic/mistakes.html
In current software development, it seems like there is a laser focus on developers (and others) *testing* their own code.
Post a Comment