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:
http://www.stephenblower.co.uk/blog/08/08/2013/bbst-black-box-software-testing-course-review/
http://theadventuresofaspacemonkey.blogspot.co.nz/2013/05/bbst-foundations-20-recap.html

Getting Feedback as a Software Tester

To start with, I think getting feedback as a Software Tester is very important.

In general, I think it’s great to solicit feedback to see what you’re doing well, what you’re not doing so well and what you could just stop doing altogether.

A man from our office gave us a presentation on personal radars and how to be awesomer, then asked specifically for feedback after the presentation and then again in an email the next day- thanking us for our time. Good stuff. No ambiguity involved. If there was anything that I think he could’ve done better, I had a green light to let him know. And what he did well? I made sure to tell him what I thought regarding that too. And you know what?! I did it Toastmaster Stylz! That’s right. The CRC approach- Commendation, Recommendation, Commendation.

I think that learning is a very important part of being a software tester.

You need to learn:

  • How to adapt
  • How to get along with people
  • How to get your message across
  • How to interpret information
  • How to experiment with different technologies

Among many other things.

OK so I’m of the opinion that to a certain extent, people are aware of what they’re capable of and what they’re good/weak at. But then, that opinion of yourself -chances are- is  not perfect. Maybe you place too much emphasis on certain weaknesses or overlook some weaknesses or maybe you underestimate the value of one of your strengths.

Therefore, because of that – getting feedback is very important.

But how does this tie in exactly to being a software tester? You might ask.

Since testing is a constantly learning journey throughout your career, I think it’s important to make sure you’re on the right track sooner rather than later. Why should you have to wait until performance review time to get that feedback when you could just have a conversation?

Now I’m going to guide you through two scenarios where I think it’d be appropriate to seek feedback:

a) Regarding your communication skills
Say, as a software tester, you’ve been having difficulty convincing other people in your team to see things from your point of view. Either the defects you are raising are being ignored (i.e. you didn’t provide enough information in the defect) or people are asking you about things that you have already covered (i.e. they don’t understand what you mean when you talk).

Asking for feedback, specifically on how to deal with situations like this, could really help.

b) Regarding your test estimation
So your test lead/manager asks you, how long will it take to write these test cases/ execute these tests/ finish testing this part of the functionality… Umm.. Ahhh.. 4 days? Yep. 4 days sounds about right.

4 days later – you’re not done. Go and ask not only for feedback on this area – but advice too.

Assuming testing timeframes get increasingly squeezed, I think knowing exactly what you can accomplish in a limited timeframe is very useful not just for you – but the person you report to as well.

Tell me, what do you think is the value in asking for feedback as a software tester?