Nicky Tests Software: September 2013

Monday, September 30, 2013

Breaking Bad Communication Habits

Breaking Bad Communication Habits


I'm sorry. I couldn't help myself. I just had to use an awesome pun to start off this blog post :) My boyfriend and I literally laughed out loud when I read the title of this blog post out loud. And yes, I'm one of those people who are usually the first person to laugh at their own jokes.. no shame.. no shame.

I've become an avid fan of the show and I'm pretty gutted to see it end. But hey, I admire the fact they quit while they're ahead instead of milking it for all it's worth.

Anywho, let's get down to business. Lately, I've been thinking a lot about communication skills. I mean, I'm pretty sure a high proportion of people believe they have 'good' or 'solid' written and verbal communication skills. But how many people actually do?

Monday, September 23, 2013

Using Mind-maps as a Collaboration Tool

Recently, I started on a new project. It's interesting. And I'm very excited about the Foosball table on-site (Note: This is possibly a massive understatement.) Anywho, I floated the idea of mind-maps past my team, they liked it - so now we're using Mindmeister. You see, I'm pretty excited. I wanted to use mind-maps in my last project, but since the rest of my team couldn't gain access to the mind-mapping tool (I was working remotely), we thought we'd skip the idea.

It's working out well so far, we've all got access to it and are currently brainstorming how exactly we're going to test the sexy piece of software we have in front of us. I particularly like the part where you start out an idea, maybe expand it into a few branches, then just leave it for a bit as you let your brain process the information.... you then log back into Mindmeister a few hours later, lo and behold, someone in your team has really helped developed your testing ideas. You, too, have also helped developed your team's ideas.

Another reason why I'm becoming quite a fan of mind-maps, is the fact there's so many ways you can organise your test case ideas. I, myself, find it interesting to watch 'live' my other team members work on the mind map and see how they organise their test case ideas, whether it be by part of the software or splitting it into different types of non-functional testing (and which of these would be suitable for the software).

Other than the obvious benefit of a mind-map helping you come up with ideas for test cases, it does have another handy benefit. It helps you understand the system and develop your thought processes visually as you explore what exactly the system entails. I'd almost liken mind-maps as a 'thinking out loud' process, where you answer your own questions by just delving deeper into the mind-map and generate more test case ideas.

Friday, September 6, 2013

But look there's a bug, shouldn't it get fixed?

When I started software testing, I was under the impression that all defects that were found before going live, were fixed. Bar some aesthetic ones which could wait a few days after go-live.

You see, I'm really now only starting to grasp the concept of time, priority, resourcing and acceptable risk. It appears that usually because of one of the aforementioned factors; a bug that I reported just continues to exist in the software and contribute to the statistics in a defect report until it is viable to fix it.

Now, in raising a defect, I do my best to provide as much information as possible for them to not only fix their defect but also make a decision on whether or not it is worth fixing; and if so - when. And here's a rough outline of what I include:
  • Defect Name
  • Priority
  • Severity
  • Environment Found in
  • Steps to Replicate
  • Description of What's happening
  • Affected Tests
  • Creation Date/ Due Date
  • Build Found in
But part of me wonders if that is enough for them to make a decision of whether or not a bug is worth fixing. The idea of writing a statement on the risk of not fixing the defect has crossed my mind, but I'm not comfortable assuming I know what exactly constitutes risk for the client.

I've found that if something just looks weird and you think that the client would be interested in seeing it - you ask to show them something. You replicate the defect in front of them and then ask what they think.

If this option is not available, part of me also wants to try something a tad unconventional. Say - putting the defect in a 'real-life' scenario, and describing the defect in such a way that the impact of the defect is clear.

For example:
You want to grab one of those awesome deals on GrabOne. (This is a website similar to GroupOn)
Look - there's a superb deal for a gym membership for $20 for 2 months.
You read through the description thinking "Looking good, looking good"
Scanning through the terms and conditions, you notice that they are rather ambiguous with when the deal expires. Offer ends 30 November 2013. Hang on - does that mean you need to start the gym membership by the 30th of November or you need to have used up the deal and finished your membership by the 30th of November?

Now, the problem is, the Start the Discussion hyperlink doesn't work. It sends you to some error page. This could deter people from grabbing the deal.


Do you add extra information to a defect in order to help it be assessed? If so, what information? Do you ever have trouble convincing someone to fix a defect because they don't think it is important/likely, even though it actually is?


Monday, September 2, 2013

Getting excited about organising a Testing Meetup


In about three and a half weeks time, the first Auckland WeTest will take place. I'm really looking forward to it and having the hard work of Shirley, Jen, Erin and I pay off.

Now here's a bullet point summary of why I'm looking forward to this event:

a) Reaping what we have sown

I'm keen to see it actually happen. When you're planning an event, it's simply an idea in your head that you're shaping to become a reality - but when it's actually happening; then that's another thing altogether.


b) Meeting people from different backgrounds and different approaches to testing

Our event will give ample opportunities for discussion and to offer your opinion. I'm looking forward to hearing what people have to say; especially those I do not agree with. I want to learn how and why people approach testing in different ways. From this event, I hope to have a better idea of the other testing approaches that are common/popular in Auckland, based on how people give feedback/ask questions on the Experience Report.


c) The Dice Game

Yes, it can be very frustrating - especially considering you can break the rules (which really forces you to think outside the square). But it's very satisfying when you finally do figure it out and think back to previous rolls and how it satisfied the rule.

d) The Experience Report

Donna McIntosh will give an experience report on Automation. Other than the fact it's a topic often talked about in testing, I'm keen to see on what she has to say about her criteria on when Automation is viable.