Tuesday, June 30, 2015

'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.

1 comment:

  1. Software Testing is an investigation carried out to provide information about the service or product to the stakeholders. It also provides and independent view to allow people to understand the inherent risks involved in using that software.("dev2one")