Day 8 —Warm Cocoa and “Works on my machine”

“Speak to a developer about a bug you found instead of raising it in a defect tracking system”

Controversial! So before I set out on this task, I decided I needed to set some goals:

  • Define when I think a bug needs to be tracked in a defect tracking system
  • Understand when a developer thinks a bug should be tracked in a defect tracking system
  • Establish a rapport with the developer that reduces or removes the tension typically associated with raising a bug.

When asking, do we need to log a bug in defect management software, its important to ask, why do we log bugs in defect management systems? Most defect management applications allows us to at least; document, categorise and prioritise bugs, with the goal being, ensuring the appropriate bugs are addressed within an appropriate timeframe. So we log bugs so that they will be fixed? But what happens, when in roughly the same time as it takes for bug to be documented, the bug itself could be halfway to being fixed, do we still need to raise it? Well this has been raised within our team and we agreed on a few points.

  • Complex to reproduce bugs should be raised
  • Bugs that cannot be reproduced, so that we have a log of when they first occured
  • Large regression bugs
  • Bugs that we cannot fix within the length of the sprint

Defect reports do have their value, but it is proportional to the time spent creating them. Spending 10mins filling in a complex defect report, for every missing comma, spacing error or the wrong shade of green may not provide much value in comparison to a 5min chat summarising all the issues.

If you fix bugs as you go, you will have less bugs overall. Its as simple as that.

All unfixed bugs, build up, and if left unchecked, will result in an application that makes for a horrible user experience, but works.

When speaking to a few developers about, when to raise bugs, the feedback I got suggested something along the same lines. Stopping work on a ticket, logging into defect tracking software and remembering how that part of the application works all have overheads. If they can fix something quickly after they have finished working on it, the code is still fresh in their mind and there is less context switching going on. As testers, this also facilitates a less hostile working relationship. Imagine you left the bathroom light on, but then you move into another room; sit down, book out, blanket on, cocoa in hand. Getting up to switch off the light may not seem very appealing, but you know you should do it. If only someone had reminded you whilst you were still in the room!

Being aware of your language and approach can also be key to bringing defects up with developers. Developers are people, people who like cocoa (or java) just as much as anyone else, so the language you use can have a major impact on how receptive a developer is to learning about your issue.

source: http://nutritionfor.us/wp-content/uploads/2012/12/warm-hot-cocoa.jpg

One simple powerful technique I was told a few years ago, is to change one word. Bug! (or Defect). Try; I have an interesting; observation, use case, or workflow. Now we aren’t presenting a potential failure in the developer’s code, but simply clarifying whether our own understand of the application is valid. This allows the developer to raise the issue on their own terms, who knows. They may even fix it on the spot… or right after their cocoa.

I have been using this approach within my current team, and can happily report that it is working well. Almost all bugs introduced as part of new work are resolved within the same day. I routinely raise bugs directly to our developers who are always happy to take a moment to hear me out.

I’ll finish today’s article with a recommendation for an excellent presentation by Martin Hynie and his talk on testing job titles to bring home the value a word can make.

http://www.ministryoftesting.com/wp-content/uploads/2014/05/WhatsInAName_TestBash.pdf

Note:
You may be asking, where is article number 7: “Find a visual way to represent your tests, e.g. a mind-map, diagram, model”?! Since I have already covered mind maps and some of my testing approaches in other articles, I decided there would be too much duplication to warrant a new article.