Aaron Hodder is an experienced and passionate context-driven tester. Before joining Assurity, Aaron worked at Metra Weather as a Test Analyst for the Weatherscape XT product, a weather graphics presentation system used by TV stations nationwide.
Aaron is active in the testing community, having co-founded WeTest, attending the peer conference KWST and presenting at STANZ on using Lean Visual methods to plan and report on testing activities. Aaron will be giving a presentation at CAST 2013 on Mind Maps – A practical, lean, visual tool for test planning and reporting

How did you find yourself being an advocate of Context Driven Testing?

When I started out testing, I was one of three testers in an organisation of around 50 developers. The testing budgets I was given was often in the order of hours or days, not of weeks or months. It was an environment where I put my hand up to be a tester, and now suddenly had to learn what testing actually was. I was very insecure for several months. I was testing in a primarily exploratory manner, and talking directly with developers, but I was worried, after all, the textbooks told me I should be writing test plans, and I should be writing test scripts with expected results, and pre-conditions. But it wasn’t working for me.

To write the test script, I had to interact with the application and learn about it. Then I would write the script. But I had already performed the test I was about to script! At a conference, I timidly approached James Bach, and expressed my concern that I wasn’t testing “by the book”. He responded, “Why would you want to test by the book? The books are wrong!”

At that moment, a door opened, and I realised that I could set up my own sail, and develop my own ideas on what testing could be; that what constituted good testing depends on the context you find yourself in. I started seeing other testers around me in other organisations writing massive test documents and saw it for what it was: mostly ceremonial paper pushing.

It was then I realised there are two futures in my chosen profession. A future in which software testers are interchangeable commodities performing clerical superficial checks and wasting a lot of money, or a future in which software testers are respected and skilled members of a software development team who bring their critical and lateral thinking skills to bear to find problems noone thought about. I know which I want to be a part of, and I try to bring as many people along with me.

I remember when we first met, you had us Grads play the dice game – what do you learn from the dice game that applies to software testing?

I don’t want to give too much away about the dice game, but it teaches that software testing is a process of learning, modelling and testing all happening in parallel. You cannot discover the answer to the dice game with loads of upfront planning and pre-scripted testing; it’s only through a variety of activities happening in parallel can you discover the answer. It also teaches about challenging the constraints of the ‘game’ you’re in (many projects are treated like games, with conditions for ‘winning’ and ‘losing’ and keeping score via bug counts and other silly things). It also demonstrates that testing can be a lot of fun!

What prompted you to start WeTest?

I co-created WeTest with Katrina Edgar. The goal was to unearth testers in the Wellington region with storie and to share those stories with other testers on the front line. It’s to build a local passionate testing community. The important factor with participating in WeTest is that if you are presenting, you must have skin in the game. You must also speak from experience. Then you must accept the challenges and questions from the participants, all of whom are also practitioners. 
This wasn’t about talking about theoreticals, this was about sharing real stories. We felt there was a gap for this kind of event. It was also important to us that it remained free for participants; we wanted testers from all experience levels to attend. We want people who may have felt like I did at the beginning of my testing career to realise that they aren’t alone, and to give them the confidence that their feelings and concerns are legitimate. Thanks to the support of Assurity, this event has remained free, and it has gone from strength to strength. Our first half day weekend workshop is coming up in November to mark one year of WeTests.

What’s the most difficult challenge you face as a tester?

There are several; I’ll give you two.
One, is the constant learning you must do as a tester. Every project has something unique about it which requires you to upskill quickly. Even having to rapidly learning about a new client, and what’s important to them, what they value, all about the problem that this software is supposed to solve, through tot he technical solution before you’ve even considered how you’re going to test it can be very challenging. 
The second challenge, and the one most difficult is communicating that the way I test may be different t how you’ve seen others test before. There can be resistance when you suggest that pre-scripting tests upfront may not be the best use of your time, and it’s easy to displace your frustration at those asking for test scripts, rather than those that make money perpetuating the folklore that testing is merely the writing and execution of testing scripts.

What’s your favourite part of being in Testing?

To me, Software Testing is where computer science and social science collide. Working out what people value, then working to give them information that align with their values is incredibly satisfying. I love software development, and I’m glad there’s a role for me in it. Working in software development means you’re exposed to incredibly talents and creative people all working to solve a problem in which often involves creative solutions.