'Exploring': my first testing experience

Michael Bolton wrote a piece in response to my previous blog post, 'Software Testing: I don't just 'break stuff'.'' You can find his post here -  'What Is A Tester?' (Developsense Blog, 25 June 2015).

His blog post has given me a lot to think about. I know now when I'm next faced with the question: "So you just break stuff all day, eh?" I'll be thinking about using those metaphors - I'm a research scientist, an explorer, a social scientist, a tool user, a critic and an investigative reporter.

But today, I'd really like to focus on the explorer metaphor.

Bolton writes: "I start with a fuzzy idea of the product, and a large empty notebook. I treat the product as a set of territories to be investigated, a country or city or landscape to learn about."

Thinking back to my first testing experience, I could safely say that Dora the Explorer would have put me to shame. I was nervous on my first client site, people spoke a lot of 'tech' with their superior domain knowledge and I'm ashamed to admit it - but despite being taught some great techniques from respected, experienced testers - I was tentative in my exploration of the large and complex system.

First day nerves definitely got to me. And it actually extended out into a week or two before I really settled into the groove of things.

One of the biggest traps I fell into as a newbie was feeling overwhelmed at how much I didn't know. Once I finally felt like I understood something, I would get tunnel vision by focusing on that tiny fragment of the system.

Put simply, I needed to think about my testing in context. I was focusing on understanding my findings but not seeing how my piece of testing sat within the whole.

I found myself thinking back to my favourite childhood picture book - Zoom, by Istvan Banyai.

Credit: Zoom, Istvan Banyai

Banyai's illustrations reminded me as a fresh tester not to think about my testing solely as the picture on the top left. My area of test was a part of a complex software system that runs through a number of processes on a cyclical basis. 

Some thoughts that were triggered by thinking about Zoom: 

• Where does my testing sit relative to the project? How does it link to what the rest of my team are testing?
• How does this piece of functionality tie into the cycle as a whole? What other related areas should I explore?
• What are the consequences of this not working - what would the flow on effects be to the end user?
• 'Zooming in' to what I'm testing - have I missed any key details out?

Now that I'm a little further along from my 'first experiences' as a tester, I've re-evaluated and come up with more questions to think about:

• Zoom is merely a 2D graphic, can we consider the entire system from a different perspective?
• What kind of value is my testing adding to the whole?
• Can I take a few more steps back and approach my testing from another angle - and in doing so, will I potentially cover off multiple areas of concern, thus making my testing more effective?

These thoughts may be amateur - but I would have never thought that a picture book I enjoyed as a primary school student would have such a lasting impact on me, especially on my career. In a weird way, the book has helped me become a better tester, a better explorer.