Regression testing can never be fully automated

In a software testing context. A regression is when a piece of software inadvertently returns to a previous state. Possibly though the introduction of a new feature or a bug fixes gone wrong.

Something which should never happen.

I have covered what regression testing is here. So feel free to read up on the subject if you’d like!

In that article. I stated that the aim of 100% of regression tests being automated should never be the goal. And in this blog post, I want to expand on that a little further.

Automating a subset of your regression tests can bring a lot of advantages to your testing strategy. From being able to free up a testing team from running long and large amounts of repetitive tasks. Allowing for increased accuracy of the tests which are run. Not to mention the distinct advantage of running your regression suite as soon as a new build of your software is released. Enabling faster feedback on the quality of your new software build.

Read More

Four ways to introduce self-care to software testers

Software testers, indeed, most workers in demanding roles around the field of technology. Can experience higher levels of stress, an inability to detach from office life and eventually, complete burnout.

With a never-ending list of tasks to complete. Stake-holders who want to know ‘is it done yet?’ And even the pressures that we put on ourselves to perform at our very best in difficult situations. All of this contributes to feelings of constantly being ‘switched on’ and a sense that it is impossible to disconnect from that part of our lives.

How many times have you read work email late at night because you couldn’t sleep for example? Or answered a Slack message about a work matter while on holiday?

Not that there is anything wrong with doing so. But having a system of healthy boundaries in place to prevent work matters bleeding into your time away from the office. Is an example of seeing something is potentially negative in your life. And then taking the steps to address it in a way that benefits you, and those around you.

Read More

The argument for being a sceptic tester

Are you the type of person that believes (nearly) everything they hear? Never questioning claims, doubting viewpoints, or thinking that you might not be getting the whole truth from people?

Or are you the type of person to challenge claims, have doubts and have a thirst for finding things out for yourself?

There is an advertisement for a wonder product that seems to promise the world and solve all of our problems.

“Can it be true?” We ask.

A policeman pulls over a driver on a Friday night and asks the driver how many drinks they’ve had.

“Only two officer.”

“Really? But you were swerving all other the road…”

Or how about when we’re told that a feature should have no bugs?

Should we believe that?

Read More

Keep your software tests simple

A big headache for a lot of software testers, especially for those who create automated tests. Or write any sort of code. Is the amount of wasted time spent debugging flaky tests, or tests that are far more complex than they need to be.


Let’s use a hypothetical example of a test that checks whether we have a box filled with a solid red colour for explaining this.


Instead of having separate test cases for checking if the box is filled in with a red chequered pattern, a shade of red that we weren’t even expecting, or that we even have a box to check.


An over-complicated test would include the logic for these extra checks, maybe calling additional test code. In addition to including the original test required of it.


This results in a test that is bloated, difficult to understand, and if something goes wrong. Harder to debug.


The test is no longer something that is adding value to a software development project. Instead, it is now a risk for the testing team.

Read More

Exploratory testing is not just ‘clicking around’ – Part 2

In my last post on exploratory testing. I shared with you the details on why we do exploratory testing. How it is done (not by ‘clicking around’), as well as the mindset of a tester when we are testing in this way.

To provide a recap though:

A tester performs exploratory testing without the help of scripted tests. Or predefined test cases. Exploratory testing relies on the knowledge and experience of the tester to explore a software product. They might have an end goal in mind. But they might not find it, discovering something else instead.

We do exploratory testing is to learn about the software. Once our tests have been formalised and written down. There is no more learning being done. Your tests are now checks.

In this post, I will share with you the ideal time to perform your exploratory tests, the tools that we can use to help guide our sessions. As well as answering some questions you might have around automating exploratory testing, when is enough exploratory testing done, as well as clarifying the advantages and disadvantages of this technique.

Read More

Exploratory testing is not just ‘clicking around’

I have written a few posts previously that have referenced exploratory testing (here, and here for example). But in those, I have only gone as far as providing a short explanation of the technique and not deep-diving into the subject.

Which is a shame because it’s one of my favourite types of testing and the one when performed well. Can be one of the more valuable tools in your testing toolbox.

Hopefully, this collection of posts will right that wrong and you can learn something you didn’t know about testing. My goal in this post is to provide a detailed explanation of the how’s, and why’s of exploratory testing. As well as show how even if we aren’t aware of it, we all use some form of exploratory testing in our daily lives.

By the way, the title of this blog post comes from an awesome talk that Alex Schladebeck gave last year and you should check it out if you want to learn more.

Read More

Where Sleeping Bugs Lie

Being a software tester is kinda like being an archaeologist. Only you’re trying to uncover software bugs rather than dinosaurs or historic artefacts.

First, you need to gather knowledge about your subject (domain knowledge). Find out where you’re likely to uncover your prize and build a hypothesis about their existence. Then finally you get to make your discovery, making sure to document your findings in a report for your developers to read.

Read More

Five Ways to Motivate Your Testing Team

Software testing can be a long, drawn-out process.

Endless cycles of testing and re-testing can negatively affect people’s morale. Leading to testers being less reluctant to work late if needed, or cover a weekend shift to track down a nasty bug that’s lurking in the system.

To get around this challenge, test managers need to ensure they are actively seeking new ways to motivate their team. But what one person finds motivating to them isn’t necessarily a universal truth that can apply to everyone.

In this article, I’ll describe some of the methods that can be leveraged to create an exciting environment for your testers to work in. One that promotes collaboration, rewards valuable work and enables you to get the best out of your testing team.

Read More

Question the purpose of your tests

‘Quick question, Can we add in some tests for x?’

‘How about making sure y works?’

I’m sure other software testers have received these kinds of questions before. And if senior management has made these requests. The response has most likely been:

‘Sure, no problem.’

We all know the negatives of saying yes to every request. Aware that we should be instead asking questions to discover their intent. But when it comes from a senior manager. Sometimes it just hard!


But as the saying goes, ‘If I asked you to jump off a bridge. Would you do it?

I recently treated myself to a new pair of running shoes. After seeing the pair I wanted online. I headed to my local running store to try them out and see how they felt on my feet.

This experience enabled me to conduct a test on the shoes to provide an answer to a question I had. But also, because I wanted an excuse to geek out on the latest running gadgets.

But that’s beside the point.

Read More

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)
Read More