Before I joined it-agile in 2010, I was exercising up to six times per week. When I joined it-agile, I knew I would be traveling more. It took me a bit more than four months until I noticed that I lacked some exercise. So, in January 2011 I started to go running, as this seems to be the only exercise compatible with a travel-rich job. Last year, I completed a 31,1 km run close to my hometown. While learning to to run, I noticed lots of parallels to Exploratory Testing. Here are the things that stuck.

You can go faster on familiar terrain

This is a lesson I had to learn early on. I remember my first exercises close to my regular stay in Hamburg, Germany in early 2011. There was a parc close by. I often ran through that parc. I had sort of a stable route around 5-8 kms. Of course, over time I became better and better at running. That was when the old routes stopped working for me.

I tried some variations in the beginning. The most conservative choices were to run the same distance twice. That was safe, as I knew already how to get back. But that was also boring.

That’s when I noticed that I needed some exploration. But exploratory running courses were harder for me. Why? First of all, I didn’t know the terrain. That also meant that I needed to concentrate more. Look for things to remember so that I can find the route back “home”. Besides the exercise exhaustion, that also exercised my brain cells.

Don’t get me wrong. I think that navigation systems were invented for people like me. For example, we visited the same swimming competition for ten years straight. It was always the same driving route. All those years I screwed up to find that route back again, even though I drove it one year for three times.

The same applies when I try to find new running routes. I am anxious that I may get lost.

When I ran the new route for the second or even third time, I always could go faster than the first time. I felt more familiar with the terrain, and didn’t need to be as anxious about getting lost.

When you are exploring, you are working “slower”, because you should be paying more attention to what’s happening. That also holds for new terrain in your applications. Because you are looking for all the stuff that could be wrong, you are slower, but you are also able to catch more bugs. This is one of the main differences to more scripted testing where you focus on one thing to check.

When running, exploring takes more effort from your brain, and is usually slower. That does not help with the training effect very much. When you are exploring while testing, the outcome of the slower progress is intentional.

You notice little details every time you run the same route for another time

When running, I noticed that over time I became more and more familiar with a particular route. That was also when I could start to enjoy the environment more and more. I was able to notice the flowers on the side of the track. I was able to notice different people. I was able to notice finer and finer details of the world.

That is also helpful when testing. Think about a session charter focused on exploring a particular bugfix. Since you already know the terrain around the bug very well, you are more open to notice new details that you were not familiar with when you visited that piece of the application for the first time.

That also holds true when you dive deeper into a particular bug in order to write a good bug report. When you try to reproduce the bug, you start to notice more and more nifty details along the road. You refine your model about the application in your head by doing so.

Since your mind can let go of some of the overwhelming details that you encounter when you run the track for the first time, it will start to work with the environment on a coarser, more abstract level, and has some capacity free for dealing with all these nice little details. You can leverage that effect when testing, too.

Avoid running up-hill too early into your course

I participated last year in a longer run that went up-hill three major mountains in our terrain. That was quite exhausting. What was even more exhausting was that I didn’t prepare well enough for these (since I didn’t know the full track) – resulting in me walking the final 4kms of the race.

Exhaustion happens when running when you go up-hill too early into your route, facing a longer remaining track. Up-hill alone is not a problem, usually. You just need to take it with a pace that works for you in the long run.

That also means that you can train for running up-hill, thereby improving your pace.

The same happens when testing exhaustively too early into a project. You will have less attention span for the more troubling bugs later into the project. The agile community often speaks about the concept of a sustainable pace. Be aware that it’s possible to burn yourself out too early into a project. And remind yourself from time to time to gently stress your current capabilities in order to improve at what you are doing.

Three lessons

These are the three main lessons I learned while running. When you pay more attention, you make slower progress. When you visit a place for a second time, you notice other details. Stick and train for a sustainable pace. These lessons also apply to software testing, and especially Exploratory Testing. Be aware of these, and you will do fine.