Bug Advocacy Part II

by | Syndicated

Last Tuesday, I gave my Experience Report on Bug Advocacy at the latest WeTest Auckland Meetup. It was a bit daunting – not that the audience had menacing expressions on their faces or anything, but I tend to do a little freak out before I speak in front of people. Something that I need to work on.

Here is the link to my Prezi.

Below is a reflection on the Bug Advocacy Meetup we had last Tuesday.

A bit of background information about my experience: I’ve never been on an Agile project. Neither have I been brought into a project early in the SDLC. By the time I’ve come on to projects, the software has already been built. This meant that some people questioned why I don’t just talk to the developer and get the bug fixed? Or why don’t I just write it on a post-it note and stick it up on their computer? While I agree that these are great ideas, I’ve been on projects where things have to be tracked in a Testing tool.

I learned a lot from the discussions that followed my experience report. Namely, how people deal with bugs when they are on ‘less traditional’ projects. I also found it interesting to see that people seem to be just as passionate about functional bugs as they are about usability bugs; arguing that the usability bugs make the software ‘unprofessional’. 


After my Experience Report, I prepared an activity which involved finding bugs in an Advanced Driving School website, using another Advanced Driving School website as a heuristic. These usability issues included:

  • The fact that the first website’s homepage was too long. 
  • You cannot easily identify the menu
  • The fonts and colours constantly change
  • Some fonts are unreadable.
  • The visitor’s count should be replaced by a conversion counter for it to be more meaningful.
I then attempted to play Devil’s Advocate and argue back at them why one shouldn’t have to fix the above issues. Boy, that really riled them up.
Good.
They explained to me why these bugs should be fixed and how some of them would be a quick fix. So given the impact of the issue, and how relatively easy it would be to fix – some of these bugs really weren’t worth arguing about.

Here are a few things that people agreed on that makes a good bug report:

  • Write a useful Summary/Title
  • Include steps to replicate. There was a developer in the room and he said it really helps.
  • Attach logs if you can. A developer should be able to tell you how/where to find/record these logs.


Here are a few things that people agreed helps you advocate for bugs:

  • Respect people’s time – if they look really busy, maybe come back later or gather a few questions before you approach them (instead of interrupting them every two minutes)
  • Create a warm, happy environment. Some Testers say they have friendly bets with developers – the losers get cake for the team. Remember, we are all in the same team.

Here’s a link to Bug Advocacy Part I