You should always break what isn’t broken

Software testers often receive a reputation of the ones whose job it is to break software. And while that isn’t true (we received it broken, we merely informed you of the issues there were already present). Sometimes for things to advance, we need to break things.

You might be familiar with the well-known phrase: ‘If it ain’t broke, don’t fix it!’ And while this applies in certain areas. I believe that not breaking or changing things increases the opportunity for issues to appear. And in software testing where it is arguably our responsibility to reduce risk. It is therefore important to know of the problems that not embracing change can bring.

Software testers often hold pride in the tools and testing solutions that they have already produced. Declaring that: ‘It’s already the best way’, amongst other such claims.

Not realising that keeping on the path they have always trodden leaves them exposed to potential risks which include:

  • The risk of using outdated testing methods
  • The risk of using ineffective tests
  • The risk of missing out on those unthought-of items (like edge cases)

Unfortunately, many people are resistant to change. Often fearing the unknown, and preferring the safety of their existing knowledge and tried and tested methods. But if only they took a moment to ask themselves: ‘What is the risk of staying with existing processes and not embracing new ideas?’

They will conclude that in the face of the fast-moving technology world we are in. They really cannot afford not to at least explore the advantages that change offers.

Be open to new ideas

Firstly, I’m not advocating that you go out and change all your tests with no kind of potential improvements in place. That would be irresponsible.

But there are areas in which we can change our testing processes, but we have become comfortable. Comfortable in the results they report, comfortable in how we execute those tests. And complacent in the dangers of not trying to do things differently.

Have you ever heard the phrase: ‘It’s how we’ve always done it’.

Ugh, what a motivation killer. Nothing kills innovation within a team as quickly as the monotony of doing things in the same way over, and over, again. This disease can spread through teams and just like a vacuum, suck all the interest from people’s work.

Just because it’s the way you’ve always done it. Doesn’t mean it’s the best way. You may not know of newer, better ways to achieve your results. That’s OK. No-one is expecting you to know everything. But you need to be open to the possibility that someone on your team does.

Also, if a particular test also hasn’t changed for a while. It may also be losing its effectiveness (see pesticide paradox).

Choose your metrics

The goal of introducing changes to an existing process should always be an improvement. That goes without saying. But is your existing process unreliable, to slow, or just hard to maintain?

There is always room for a shake-up in existing processes, and while we should never be comfortable with them. Being able to see their flaws and using those insights to drive innovation; is an important step in deciding where to focus your efforts.

Often we aren’t aware of the flaws in our processes before it’s too late. Issues being compounded into one big bug explosion that rips a hole in our product.

Save yourself and your team by defusing this bomb before it’s deployed. Identify the potential improvements and allow for experimentation and growth to occur.

Optimise and Innovate

I’m sure you have some smart people on your team. That’s why they found themselves working with you, right?

Embrace that knowledge to find the successful solutions that you need.

The best way to take onboard knowledge is to share it with others. So work with your team, collaborate on introducing targeted process change. All the while promoting a culture which allows for the sharing of new ideas without hesitation.

Breaking things is not just about disabling something that functioned previously. It’s about the deconstruction process. Analysing how we put something together. Seeing its flaws for what they are. And then putting it back together, with better pieces than before.

Change is hard and change is scary. But we need to break that fear if we truly want to innovate on our existing solutions.

Posted by Kevin Tuck

Kevin Tuck is an ISTQB qualified software tester with nearly a decade of professional experience. Well versed in creating versatile and effective testing strategies. He offers a variety of collaborative software testing services. From managing your testing strategy, creating valuable automation assets, or serving as an additional resource.

Leave a Reply