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
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
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?
- 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.
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.
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.
- Split it up into paragraphs
- Use italics
- Underline subheadings
- Use bold to highlight important sentences
- 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.
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: