Not having an approach causes problems in your testing

We all know what a test approach is, it’s that document that we write to say what we’re going to test. For some testers it’s seen as boilerplate or a waste of time, but I’m here to tell you that not having one can cause problems in your testing.

What’s an approach?

A test approach is something that communicates the who, what, where, when and how of testing for a project. It can take many forms, like a document or presentation, and aims to share the thinking that goes into your testing. Essentially it’s a plan for the testing that we need to do on a project and what we need to get done to allow that testing to take place.

An approach isn’t a specific template; in fact it’s better for it to not be from a template because then you’ll think about your approach and tailor it to your needs.

Missing scope

If we don’t make an approach or plan our testing we’re likely to completely miss areas of testing that needs to happen. It’s hard to think of things holistically so it’s easy to miss things in the moment; an approach gives us time and space to think about what we need to get done.

Features, integrations, up or down stream functions and non functional considerations might not get added to requirements / Stories / ACs so easily get forgotten. By documenting everything we want to look at in an approach we can clearly set out our full scope and make sure everything gets tested.

Assumptions

If we don’t communicate what needs to happen, how it should happen and who’s going to do it then people will have to guess. Assumptions on testing can lead to mistakes like “oh I thought you were going to do that” meaning testing gets missed.

We can’t assume others will have the same understanding as us for terminology or even how to test (what does exploratory testing mean?!?) This means we need a way to communicate to others specifically what we mean and expect to happen so that everyone is on the same page. 

Assumptions that come from a lack of understanding means that we might not conduct some testing, get the testing wrong or not act on the results of testing. All of these things can lead to an overall lowering of testing and quality of what we’re working on.

Nobody knows what you’re doing

Part of being a trusted advisor in a team or selling testing is to set out a contract between yourself and the team. We want to say “here’s what I do, here’s what you can hold me to account for” to start building an understanding of what we bring to the team. Without an approach or plan we may take an adhoc approach to testing or chase things down in a way that others can’t understand, leading them to start ignoring us.

If people don’t know where and how you can help, you may end up getting excluded from important conversations. An approach can help people to know when to include you and in which conversations (especially if you tell them how).

If nobody knows what you’re doing then only you can pick those things up, this makes your testing uninheritable (if someone else needs to join your team). We need an approach to help others hit the ground running when it comes to testing, that means all team members and not just other test professionals.

We’re not aware of blockers early

Without a plan for what we need to do and, importantly, what we need in place to do that testing we might miss blockers. What happens if we don’t have any 3rd party test data? What about if suddenly we get lots of UAT testers join expecting to do *SOMETHING*? Without a plan we can’t solve things in advance and have to react / firefight which will impact the quality of your testing.

If the blockers are found too late to act upon it might mean that we miss doing important tests. I’ve seen teams before saying “oh we just can’t test that” and the reason usually is because they didn’t work out how to get what they need early enough and it’s too late. 

Scope run rampant

Without a clear plan of what we will do and what we won’t do and accountability for work it’s hard for us to push back and say no. This can mean we end up picking up everything and anything that people think of, like getting stuck testing based on people’s issue of the moment. This might not be important to the team, but without a plan you’re unable to push back by saying what else you should be doing.

We may also have massive scope creep ourselves by digging in deeper and deeper into an area to find ALL THE BUGS to the detriment of other testing. How often have we spent too much time trying to unravel all the information of one thing? By setting out scope in a plan or approach we can see that we have more things we need to get done, then plan our time accordingly.

Wrong type of testing

By not setting a clear holistic scope of our testing and identifying the right ways to test we also can get stuck doing too much of the wrong testing. How many teams get stuck running cycles of manual regression because there’s no plan to implement any automation? Running the wrong tests means that we miss important areas of coverage and can miss bugs.

We can also get stuck not using our skills to their fullest,. Having to focus on managing SMEs doing UAT when you’re a deep technical Automator means that the team isn’t getting the best out of you and testing will suffer.

With an approach, we can set out what testing we need and where, or be able to see what we’re missing and need to work towards. Think of it as having a target that we want to aim for and achieve. Without a plan, we may just end up doing what’s easiest over and over and miss out on important test coverage.

To conclude

A lot of the time testers can just dive into organisations or projects and start testing without setting a plan or approach. This leads to us missing out on important factors to our testing, not looking to test everything or just doing the wrong thing. Without stopping to think, we can easily get trapped in the weeds or stuck firefighting in the small and not consider a more holistic view of our testing.

A test approach isn’t just about ticking a box for the regulators or to meet an ISO standard, it’s there to get you to think about what needs doing and how to get there. It’s a tool we can use to make sure our testing is COMPLETE, FIT FOR PURPOSE and COMMUNICATED WELL TO OTHERS.

Whether you’re starting on a new project or part of an existing one, take the time to stop, reflect and check on your approach – it’ll help your testing.