Intermittent bugs can be a frustration for not only testers but the rest of a team. You may be lucky enough to uncover it before it reaches any beta testers or you may find yourselves having to figure out what the hell happened because a customer (or several) has reported it but you are struggling to replicate it.
Here are some ideas on how to deal with intermittent bugs.
Continue reading “Dealing with Intermittent Bugs”
Here’s a step by step guide on how to write a bug report /defect report.
First, we need to ask ourselves a few questions:
- Why are we writing a bug report?
- So there is a record of the behaviour
- So that the bug gets fixed – for the bug to get fixed we need to provide clear enough information so the developer can act upon it and the product owner/manager etc can decide how to prioritise this bug and if it should get fixed.
Continue reading “How to write a bug report /defect report”
I recently completed the BBST Bug Advocacy course and am currently waiting to hear whether I passed or failed. I was somewhat freaked out when I got sick (a damn cold) during the exam period and found myself having to reread the questions multiple times before I could figure out what I was supposed to do (thanks to my headache at the time). To add to that, none of the questions I practiced for were in the exam (I reviewed for about a third of them) so the first word that went through my mind when I went through the exam was S***. I ended up splitting up my answers into multiple sections so that I could actually understand what I needed to do (this turned out to be something the reviewers really liked funnily enough). Enough of my wee rant, below are my biggest takeaways from the course.
1. Irreproducible bugs should still be raised
Continue reading “My 5 Biggest Takeaways from the BBST Bug Advocacy Course”
After my Google Hangout Interview with Katrina, I started to think about picking your battles – which she listed as an important quality of a tester. Below I’d like to talk about my experience and thoughts on this idea.
The Girl Who Cried Wolf
When I started my first (ever) project, my understanding was that the purpose of testing was to provide information with more emphasis placed on advocating for the fixing of bugs.
The thing is – I took this too far.
Part of me relished raising bugs in the Test Tool and assigning a severity and priority. The sad thing is, I thought I was a better tester when I raised bugs with a higher severity and priority. This meant I probably assigned a higher severity or priority to bugs than they actually deserved.
I’d see spelling and grammar mistakes and would make a massive deal out of it. It took a while for me to learn that my opinion mattered but wasn’t actually as important as I thought it was at the time. Looking back, I didn’t try to see if the spelling and grammar mistakes could change the meaning of text – I merely marked it as wrong. If I were to come across this situation now, I would consider the impact of meaning on whether I were to assign a higher severity/priority. (For example: Would the bad grammar lead the user to commit an error?)
Unfortunately, this led to a “boy who cried wolf” situation. I found it more difficult to get my bugs fixed partially because of the fact I placed too much importance on bugs that didn’t actually matter (and partially because of factors out of my control).
Why should you pick your battles?
- To not cause the testing profession to be seen as a a blocker of the SDLC
- To avoid a “boy who cried wolf” situation
- To ensure we (as testers) are seen as adding value to a team and not hindering the team
How can you pick your battles?
Here are a few questions you could ask yourself when advocating for a bug
- Why do I want this bug to be fixed?
- What’s the worse thing that could happen if the software went live with the bug in it?
- What’s the risk of the bug being discovered in production?
- Have I made a reasonable effort to see things from the other person’s point of view (if someone is saying the bug does not need to be fixed)?
- Looking back, are there bugs I insisted on being fixed, that were in fact not that important? (this may affect the current perception by the team)
- Have I asked the opinion of someone (honest, who won’t just blindingly agree with me) about the bug and presented the bug in an objective manner?
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 visitors’ count should be replaced by a conversion counter for it to be more meaningful.
I then played Devil’s Advocate and argued back why one shouldn’t have to fix the above issues. That really riled them up.
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
It’s important to communicate effectively in order to advocate for your bugs in the best possible way – whether that be written or verbal.
One of the things I learned from my BBST Experience
is that the use of formatting can really help you get a point across. You could:
- Split it up into paragraphs
- Use italics
- Underline subheadings
- Use bold to highlight important sentences
In addition, being able to drive your point home by talking to someone face to face really helps too. I learned some valuable tips from Wil McLellan
at a previous WeTest Auckland meeting.
Credibility helps get your bugs fixed. As a consultant, I’ve had to learn to gain credibility on each project.
I’ve learned to do this in a number of ways including:
- Be professional – I aim to do this through not only the way I dress and how I talk; but I also make sure I sing someone praises so that they get the recognition they deserve (this is something I am rather passionate about especially since some people are better at ‘selling themselves’ and others can be shy but super talented)
- Yet friendly – I’m generally a happy chappy and from what I can gather, I’m approachable too.
- Consistently raise good bugs – I do my best to provide enough/sufficient information on each bug report. I also talk to the developers or business analysts for tips/advice before I raise the bugs or feedback after I raise them.