How to avoid being fooled in software testing

As software testers, our role is to avoid being fooled by stuff that is potentially fooling others. For instance, we try to avoid being fooled by the product, we do that by testing with more than one piece of data. We try to avoid being fooled by stories as they are incomplete, ambiguous or out of date.  To avoid being fooled we often challenge our assumptions or the team’s assumptions of what we know. With the help of the trainee testers from Test-Ed we compiled a list of ways to be avoid being fooled

My top ten ways to avoid being fooled. (I’ve deliberately kept these high level as I believe these strategies work across all levels and types of testing).

Diversify your actions

Mix up your actions. Do things you wouldn’t normally do. Try performing the same actions or journey using alternative methods.

Diversify your test data

Are you using the same data all the time? Think about mixing it up.  Use tools and methods to help improve the quality of your test data.

Diversify your oracles

How do you know you’ve found a bug? Are you using the same Oracle time over? Consider mixing up your oracles.

Diversify who is doing the testing

We all see different things and have different experiences, so mix up who is doing the testing for different test ideas and different views on what is a problem/or not.

Diversify your test environment

Your test environment most likely is not a replica (yet) of your production environment. Consider using different test environments to expand your knowledge of the system. For example, a constrained test environment may offer interesting information on how your system performs under duress.

Diversify the starting point

Don’t start in the same place every time. Change the state from where you begin your test.

Question your source material

Stories can be incomplete, out of date, hard to test and or ambiguous. Query the story of this is the case.

Ask Why?

It’s fine to follow process if it makes sense. But if you can’t explain why you are doing something one way, you may be fooled. There may be a much smarter way to perform the task at hand, so there’s no harm in asking why something is being done this way.

Clarify meaning

It’s easy to assume that everyone is on the same page when it comes to definitions and meaning of words. If you are unsure of a meaning, chances are you are not the only one, so no harm in asking.

Diversify your model

Functionality is only one dimension of a product. There are many others. Consider the architecture, the business processes, the interfaces between stories/systems etc. The more you “see” the more ways you can test.

I bet there are many others ways to avoid being fooled, why not share yours?

I would like to thank Connor, Adrian, Daniel and Hieu the trainee testers from Test-Ed for their assistance in compiling this list.