2018 on Heather Reid's Blog

What Are Your Most and Least Favourite Aspects Of Software Testing?

Thu, 16 Aug 2018 15:52:33 +0000

This blog was originally posted on Medium.

Sprint 7 in the Bloggers Club is a fun one, I could write about this for ages but I’m going to try to restrict myself somewhat here!

Least Favourite Aspects Of Testing #

Missing bugs. Despite all the advice to not shoulder the burden of the guilt with this, I always do. I hate missing bugs, particularly if the customer is the one who ends up raising it with you. I feel like I’ve done a terrible job and that everyone thinks I’ve done a terrible job, even if this isn’t the case.
Raising Bugs. Despite 1 above, I don’t enjoy raising bugs. It’s that look on the developers face “Is she going to ruin my day or just ask if I want a cup of tea?” I much prefer to find potential issues before a line of code is ever written but that’s not always possible.
The debates that often become battles about what value software testers actually provide. If people don’t see you raising bugs, you’re clearly no value, right?

Favourite Aspects Of Testing #

Exploring. I love exploring a product to learn how it works. My first few days in a new job are usually when I ask to be told nothing about the product and let me explore. This helps me gauge how intuitive the product is for users before I start getting biased by what it should do or being there too long to notice the little things that are just not nice for a user.
That feeling you get when a customer gives you good feedback about the product that you helped the team deliver. Things like “Where has this been all my life? I love this product!”, okay slightly over dramatic, but you get the idea.
Community. I was previously a developer. It often felt like Google was my only friend when I needed help. I could not believe the community that software testing had when I first found it. I’m usually only ever 2 or 3 degrees of separation away from finding an answer to my questions. It’s good to have people you can talk to when you’re a lone tester and it’s especially good when those people help you get answers quicker so you can move past obstacles faster.

Loving participating in the Bloggers Club and looking forward to reading the responses from others.

Software Testers Cannot Catch Everything

Wed, 25 Jul 2018 21:06:14 +0000

This blog was originally posted on Medium.

The Bloggers Club-Sprint 6: What’s something that seems obvious within your profession, but the general public seems to misunderstand?

It’s taken me until Sprint 6 of the Bloggers Club to finally get back to blogging.

The Possibilities #

I still consider myself to be in the software testing/QA industry by the way! I’ve thought a lot about this one. Some common presumptions I have heard are

Software testers just press buttons
QA/Software testers are failed developers
You need a degree to be a software tester
Or the counter to that, anyone can be a software tester if we just tell them they have to be
A software tester cannot use someone else’s application without being critical of it

The Focus #

Finally, I settled on “Software testers cannot catch everything” after hearing some comments at home about buggy apps.

Picture the scene; you open an app, you’re midway through the signup process and you hit a bug. What’s your initial thought?…….“How did they miss this?” You’re thinking “Dammit sign up is where I decide whether I’m going to use this or not. How could they not have caught this bug that I’ve found.”

Zoom out from that thinking now.

How big is the app? How many user journeys or user flows are possible in the entire system? Hundreds? Thousands? Millions? More? I’m not here to make excuses for teams I have no involvement in, just to make you think more about this.

The Story #

I was previously on a team where there were 6 full-time developers, a UX designer and me, the lone tester. We had a LOT of ways that a user could be on-boarded with our product. There were so many from the UX perspective that there were flowcharts. So.many.flowcharts.

The UX designer was a well clued in guy, we worked closely figuring out alternative flows a user might take around the flows he had in the charts. I drew out my own big A3 flow diagrams, an individual one for each step on his larger one. We thought about the user that locks their phone midway through on-boarding process 1 at step C etc. In summary, we believed we had thought of everything or at least we believed we had thought of enough to cover the vast majority of cases with some interesting edge cases.

The dev team took a stab at the on-boarding process from different browsers, devices and approaches once I had tested it. We were all sure we had covered all the scenarios we could think of. Confident, we pushed the changes to production. Go team, another successful release! Everyone testing the whole way from design to release and testing on production. High fives people.

And then, 15 minutes after the code was live, we got a support ticket. There was a user trying to sign up and they met a showstopper bug. That is what we call a bug that completely prevents the user from continuing what they were doing. Of course, the first question was “How did this happen?” Support followed up with the customer to see what steps they had taken to get to this point. Our developers frantically checked the logs. There was a user journey we had completely forgotten about. We hadn’t planned for it in UX, development or testing.

Of course with the benefit of insight into this issue, you can see how this happened. You can see how this wasn’t any one person’s fault. Many discussions had happened. The team was human and forgot one thing. It happens.

The Conclusion #

Bugs happen. They might be small. They might be massive. A bug, usually, passes through many hands before it ever gets to the customer discovering it.

There are many reasons or ways this might happen. The example above is just one. Software testers, software developers, UX designers etc can’t catch everything but they can try to catch the worst before it gets to the user.

TestBash: Looking after Our Speakers Through Good Communication

Thu, 24 May 2018 20:11:04 +0000

This blog was originally posted on Medium.

One thing you can’t really run a conference without is speakers. Even before I joined Ministry of Testing, I knew that they valued their speakers. Once I joined, I knew I would, and should, strive to keep these values for every event we hosted.

It started with Brighton. Each speaker and workshop host got an individual acceptance email. “Yea and?” I hear you say. Except for a couple of occasions, each of these people continued to get individual emails. I checked how their travel plans were coming along, did they need advice on sights or transport. Others wanted to check in regularly which was pretty cool. I felt like as we got closer to the event, I knew ones I hadn’t even met before. Or at least knew them enough to strike up a conversation with them.

This gets a bit more difficult when your speakers are in different time zones. I didn’t want these people to feel like I was any less available for help. I did adjust my schedule to make sure I was able to catch all the timezones should the speakers have any questions for me.

After the event, I got to email the speakers some more! We pay speakers expenses so it was time to get those payments sorted. Again, I emailed or slack messaged each speaker individually. By this time, I had learned which was the preferred communication method for each of the speakers. Dan Billing said, “That must take you ages”. It did take me quite a while but I thought it was a nice touch to finish out the speaker’s interactions with me. Dan agreed when I explained my thinking to him “That’s a really nice thing to do!” It doesn’t hurt to ask how the journey home went, did their family like the gifts they had bought them etc. Geoff Lokens sign off made me smile “I’ll miss our daily emails :P”.

So I decided to keep doing this. For the Netherlands and Dublin, I have done my best to keep to individual emails for everyone. It’s not always possible to send those individual emails, but let’s do our best to show our speakers that we care. Let’s encourage them to want to speak again. Let’s help them feel like the rockstars that they are for getting up there and sharing their stories and helping people learn.

What about the people who don’t get to speak? Well, this is the hard part. We go through the unsuccessful abstracts and Richard has the awful job of telling people “We’re sorry but your abstract was unsuccessful…”. This is not something that any of us enjoy doing. Richard offers that we will give feedback to people who were unsuccessful about why this might have happened and what they could do differently.

This is another thing that does take a LOT of time but it is worth it in the end. Many people who were unsuccessful in the past took feedback on board and have since been on a stage either at TestBash or another conference. We don’t have to do this, we want to. The Ministry of Testing motto has always been “co-creating smarter testers”. We can’t do that if we remove ourselves from the community or take an approach of “You didn’t get in and you’ll never know why”.

Love your speakers. Value their time. They are awesome!