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.

To be able to uncover the truly valuable errors in your software. You’re going to have to do your homework. It’s not simply enough to have excellent technical, or software testing experience (although those do help in thinking like an end-user).

Why is domain knowledge important?

Testing should always be performed with end-users actions in mind.

• What actions are they likely to do?
• What are their expectations?
• Does this make sense to them?

Possessing that knowledge from the start is a big advantage to you as a tester. Not only does it provide the knowledge to understand how the software is likely to be used. But it also allows you to test software and applications in a more targetted way.

Let’s say for example you are testing a banking application in which you are providing a service to external, and internal customers.

There will probably be a lot of terminologies thrown around that would be an advantage to know when you are first introduced to the project.

But don’t worry if you don’t have all the knowledge you need from the off. A lot can be gathered as you get more familiar with the software. And by the end, you will have soaked up much more information then you started with.

Just try to approach projects where you don’t have prior knowledge with an open mind. Learn all you can and your understanding will be much easier.

The best bugs are hidden from view

Have you ever lost something and then found it again when you aren’t looking for it?

In my experience, software bugs can appear at unexpected times. When performing routine actions, or when you are moving been parts of an application.

That’s why exploratory testing is the most valuable testing you can do. As opposed to more formal, scripted testing. Exploratory testing relies on the understanding of the user to guide the testing. Enabling the tester to try scenarios that are tricky to create scripted tests for.

There are certain areas in a piece of software that are most at risk of bugs appearing. And that is where exploratory testers should focus their efforts to enable a high ROI for their efforts.

Below I have listed two of the most lucrative areas that have the potential for finding hidden bugs in software. As well as some tips on identifying those areas that are worth your while to investigate.

Where things are a bit iffy

Situations get complicated when there are multiple choices to make.

If you are in a car without a GPS system to guide you. Do you take the first exit at the roundabout? Or go straight on?

We can often be overwhelmed with the potential number of choices on offer. Becoming paralyzed while we try to compute the potential outcomes, hoping that we make the ‘right’ decision based on the number of input variables at our disposal.

With software that is supposed to perform actions based on user parameters or even external information (if X is this. If not, do the other thing). Errors in a program’s control flow can lead to unintended behaviour, mysterious errors, and ultimately confused users.

The good news for testers is that these ‘if’ cases can a potential gold mine software bugs waiting to be uncovered!

Incorrect outputs can manifest themselves in a number of different ways. From mysterious error messages, unexpected behaviour, or the application simply crashing on you.

If the output of a user action can one thing or another. It is most likely worth your while to investigate it.

Ch-ch-ch-changes

Imagine you are learning to juggle.

You are started off with just a single ball. Throwing it up into the air with one hand. Catching with the other.

‘This stuff isn’t so hard.’ You think to yourself.

Then another ball comes into the mix. You’re now working a little harder, ensuring you don’t drop any of the balls. But it’s still relatively easy and although you are feeling the heat. You are managing to keep it together.

Then another ball is added. This is where you now realise that this stuff isn’t a walk in the park. Your hands and eyes are now working overtime and sweat begins to form on your brow.

Then as more and more balls are added. Your ability to juggle goes down the pan.

We can conclude from this short experiment that a person’s ability to juggle, diminishes as the number of balls increases. Or to put it another way, when we introduce change.

In software, changes in the state of a program (the area of focus for the software). Can be one of the more lucrative areas in which to discover potential errors.

This is because the software either has to create new objects. Objects which may have been coded with flaws in them (especially if the developer isn’t doing unit tests). Or is required to hand over information from one part of the program to another.

You need to be curious.

This is only a couple of areas in which I find the most of the bugs in software. But there are many others that can be the source of many of your software problems.

From in-browser editors to date pickers and field validation. The potential for errors in our software is massive. We just need to ensure that we are looking in the right places.

Be curious about the actions of certain features. Ask questions to yourself about why you think something should work in a certain way. Then perform an experiment. See if you were right.

If you’re right. Great!

If not. What is going on? Be curious and interested in the result that is produced. It may be wrong. But sometimes what’s wrong, is more interesting than what is right.

• Category: Software Testing