Getting started on a testing project

I started on a new project a few weeks ago and thought it would be a good idea to share a checklist for what new testers on a project need and some good starting questions when you, as a tester, are new on a project

Checklist for what new testers on a project need (Note, your project may not include all of the below)

Continue reading “Getting started on a testing project”

The Girl Who Cried Wolf – Picking Your Battles

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?

Bug Advocacy Part II

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

Bug Advocacy Part I

Communicate Effectively

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.

Gaining Credibility

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.

BBST Foundations: Is it for me?

This blog post is not a promotion for the BBST Foundations course, but it  may seem like it – considering I’m very happy with how it went. This blog post, however, is an attempt to address any questions, that may be going through your head when considering this course.

Note, these are solely my opinions. Feel free to challenge them where necessary. I’d love to hear where others stand on this.

Why should I even bother with BBST Foundations? I’ve already got my ISTQB Foundations and/or a Computer Science Degree.

From what I gather, Computer Science doesn’t focus a lot on Testing. BBST Foundations does.

With regards to ISTQB Foundations I’ve always felt it was a test of your memory. However, I can’t comment on how it works further down the track with the advanced exam and so on.

I found the most useful part of ISTQB Foundations was to learn “common terms” and have people refer to things in the same language (well ideally, but some words are more widely interpreted than others it seems).

The most useful part in BBST Foundations was the constant feedback from the instructors and the peers along with the focus on communicating information clearly.

My point is – I honestly don’t think they are strict substitutes for each other. I would think seriously about why I’m taking a Testing course – and based on that decide whether to take BBST Foundations or advanced ISTQB Exams.

I’m really busy and am worried about the time commitment.

I’m not going to sugar-coat it: It’s not easy. You will have to carefully manage your time for four weeks.

From my experience (I did it in April this year), I spent 15-17 hours a week on this course. I’m also under the impression that others committed about 12-17 hours a week to this course.

If you can’t commit at least 10 hours a week to this course, I would seriously consider looking into the another intake.

What’s the biggest benefit of BBST Foundations?

It depends on who you ask. For me it was the constant feedback and the focus on communicating information clearly. I also really enjoyed learning about heuristics. I honestly think heuristics will be one of the most useful things I’ll ever learn as a Tester. But others may beg to differ and have benefited in other ways.

I’m planning to switch careers to Software Testing – is this course right for me?

Probably not. I found that most people drew from their past experiences when participating in discussions. At least a year or so experience would be good.

Who would you recommend the class to?

  • People who want to improve their test skills
  • People who value feedback
  • People who are eager to learn about testing

Here are some blog posts which will shed some light on others’ BBST Experiences: