Software testers are often under pressure to ensure that the testing we do covers as many of the inputs of an application as possible.

But exhaustive testing is not possible due to multiple reasons from time restrictions, to complexities in software and variables in the environment.

There is a ceiling to testers abilities that can be a lot lower than the number of features, paths and sequence of operations in software projects.

This can often lead to a tug of war occurring, with one side being testing too much. The other, too little. A fine line we have to navigate if we are going to be able to say that we are confident that a certain feature is working.

Read More

When assessing the tools to take care of browser automation to test your new web app. You might instinctively be drawn to Selenium, Cypress or maybe alternative solutions like Puppeteer.

These established libraries are perfect for building frameworks that test the whole of your web application. Whether it’s an eCommerce site, CRM tool, or SaaS product. These tools have been tried and tested by many people, in many situations. And have been proven to be the right solution for most peoples needs.

One of the problems that Selenium has is there is a learning curve to using it well. A learning curve that can be quite steep if you don’t know your way around the DOM. Or know your CSS selector from your XPATH.

Read More

Agile is one of the most popular methodologies applied in managing software development. Instead of the term representing a single way of working. There are instead several frameworks which all fit into the umbrella term that agile represents.

From Scrum, Kanban, and one of my favourites, Scrumban. Agile is well suited to modern-day software engineering in which the requirements and plans can constantly change. It is a methodology that can adapt to the projects ongoing needs. And not be rigid and stuck in the ways of only doing things a single way.

One of its main advantages over other methodologies like the traditional waterfall approach. Is that it minimizes risk advocating the use of using time-restricted iterations called sprints.

Read More

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

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

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

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

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

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 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

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