Becoming a better developer by thinking like a tester

I’ll let you into a secret, if you promise not to tell anybody.

Being a good tester is based on one thing and one thing only: Looking for the gaps.

Yes, that’s it. That is all there is. Of course there are a lot of different types of gaps, but they are all gaps. Gaps in the requirements, gaps in the design, gaps in the code, gaps in the deployment. Gaps everywhere. Some are quite difficult to find.

In some ways testing is a profession of “glass half empty” people. It’s all about looking at a piece of swiss cheese and seeing a collection of holes held together by some cheese.

What do I mean by gaps?

Gaps are those questions that nobody else has asked.

Because software development is a human activity, there will be oversights. There will be gaps in the translation of the original human intent into what the computer is told. Maybe an accurate translation is not even possible. If those gaps aren’t managed correctly, you get defects.

The role of a developer is to create that translation. They will look for ways to get things working. They are focussed on what can be achieved. They are looking at assembling the pieces to build the structure. The positive is where their attention is and that’s what they will see.

The role of a tester is to look for the oversights. They will look for ways to break things. They focus on what was missed. They are looking for the gaps in the structure. The negative is where their attention is and that’s what they will see.

The important thing here is that this is a different way of looking at the same overall problem.

That’s why it is difficult for the same person to play both roles. A person can play either role in a given scenario, but it takes a big, conscious mental shift to go from one way of looking at a piece of work to the other. If you can manage the shift though, your work will be all the better for it.