Bloggers Club: Implementing Change

I’ve written a fair bit about implementing change in the past, including two articles at the Ministry of Testing site on Introducing Colleagues to Exploratory Testing and going about implementing change when you’re not a manager.

However, in this post, I would like to dive deeper into how the status quo bias makes implementing change rather difficult.

Status quo bias is evident when people prefer things to stay the same by doing nothing or by sticking with a decision made previously.

https://www.behavioraleconomics.com/resources/mini-encyclopedia-of-be/status-quo-bias/

One of the key aspects of the status quo bias that makes it so difficult to implement change is that it’s generally easier to do nothing i.e. to not try and implement change in the first place. Even if people are unhappy with how things are, you’d be surprised by how the same people may not be open to ideas to change – that would help fix what is making them unhappy.

Continue reading “Bloggers Club: Implementing Change”

Learning how to hold retrospectives

A few months ago I volunteered to help hold retrospectives in our cross-functional team. Up until then, we had a delivery lead hosting most of the retrospectives and from time to time a process designer would also come in and host retrospectives.

The thing is, while we were going through the motions of having a retrospective, including creating actions – I couldn’t see any improvement that resulted from having these retrospectives (there was no follow-through with the actions). After talking to the tech director about the possibility of helping host retrospectives, I also spoke to the delivery lead about it (who was more than happy to be relieved of that responsibility as he already had plenty on his plate).

Continue reading “Learning how to hold retrospectives”

Why it’s important that it’s safe to fail

When my daughter started to learn how to walk, we immediately started buying corner protectors and had multiple scans of our apartment to see if there were any dangers lurking that we had to remove or cover up. We wanted to make it safe for her (to fail).

When it comes to software development, I think it’s also important to make it safe for people to fail.

People make mistakes.

It happens to everyone – and in my opinion, it’s not a bad thing.

Continue reading “Why it’s important that it’s safe to fail”

Minimalism and test documentation

Outside of work I consider myself a minimalist.

The definition of minimalism I most closely align with is

Minimalism is a tool to rid yourself of life’s excess in favor of focusing on what’s important—so you can find happiness, fulfillment, and freedom

https://www.theminimalists.com/minimalism/

For the past few years I’ve done my best to not over-consume and to donate or sell things when they are no longer providing value to me.

Continue reading “Minimalism and test documentation”

Waterfall, Baking and Slow Feedback

One of the things that frustrates me the most about baking is the fact I don’t tend to find out whether or not my baking was a success until the very end when I slice into that cake or bite into that cookie.

Even attempts to check out how things are going don’t guarantee good results – you can look in the oven to see if the cookies look like they are the right colour before you take them out, or you can use a fork to check the doneness of a cake or muffin, but these checks are only looking for one aspect of quality – doneness.

Continue reading “Waterfall, Baking and Slow Feedback”

Bloggers Club: First day in a team

I’ve had many first days in a team since I started my testing career almost nine years ago. But it’s always been daunting and there’s a lot to take in.

New faces.

New names.

New context.

New project.

I’m often trying to gain my bearings and not necessarily looking to start testing on my very first day. (For getting started on a testing project, read this)

Continue reading “Bloggers Club: First day in a team”

Feedback: Solicited vs Unsolicited

I tend to be wary of giving unsolicited feedback in general, even with the best intentions, it doesn’t always go down well.

Let me give you an example: I used to work with a tester who wrote the bare minimum when it came to bugs. There was hardly ever any information on steps to reproduce, no information on OS version, screenshots sometimes were provided and actual result vs expected result were never there.

Continue reading “Feedback: Solicited vs Unsolicited”

Dealing with Intermittent Bugs

Intermittent bugs can be a frustration for not only testers but the rest of a team. You may be lucky enough to uncover it before it reaches any beta testers or you may find yourselves having to figure out what the hell happened because a customer (or several) has reported it but you are struggling to replicate it.

Here are some ideas on how to deal with intermittent bugs.

Continue reading “Dealing with Intermittent Bugs”

Bloggers Club: What’s the most fun you’ve had with a bug

Project context: 

At my first ever project, I was one of the UAT testers for an internal application (only business user facing), where you would have to create different types of profiles (for people or for organisations) and then later edit those profiles or use those profiles to do certain things (I can’t be too specific sorry).

The approach we took was to write test cases based on the requirements and then when the SUT (Software Under Test) was ready, we would then execute those test cases.

  Continue reading “Bloggers Club: What’s the most fun you’ve had with a bug”

Tackling Test Automation Part I: What problem are you trying to solve?

For the past seven months, since I came back from maternity leave, I’ve spent the majority of my time focussing on test automation. I have both set up a test automation framework as well as overhauled two existing test automation frameworks for mobile (both Android and iOS).

But one of the struggles I have faced is not getting lost as to fail to see the forest for the trees. During the day to day, it can be easy to be constantly knee deep in code and forget the problem I am actually trying to solve. Why am I actually doing test automation in the first place?

Continue reading “Tackling Test Automation Part I: What problem are you trying to solve?”