TestBash Retrospective #4 - Automation: Time to Change Our Models

Automation: Time to Change Our Models

Mr Iain McCowatt took a relaxed but jaunty stance and delivered the first words about his talk on automation: "This talk isn't about automation".

And therein lay the point. He continued: "It's about people". This was a talk about replacing testing as a goal with the purpose of testing in the context of our tools. Seeking out what to automate replaces the question of why automation in the first place, and how?

A great little heuristic I latched onto was changing perspective from automation as a replacement for the test process to using tools as an instrument (as a scientist would use a thermometer. The example used was the invention of the barometer in solving a liquid dynamics problem.). But it doesn't stop there! How you view your tools also provides a filter for your choice of tools - and your choice of tools will change your behaviour and how the testing problem is perceived. Getting this wrong at the outset corsets the possibilities and the value that testing can provide.

There was also talk of our mental constraints which can poison people from solving problems. The example used was testers asking for access to the production environment. Why? Because they needed to do something there that they couldn't do in the test environment. Why? Because they can no longer do testing in the test environment. Why? Because there's no more disk space in the test environment. So the belief that they couldn't ask for more disk space lead to a bad solution to a fairly simple problem. The use of WHY as a powerful questioning tool against imposed constraints I think was a glaringly obvious and often overlooked and forgotten point. Another example given was goal displacement - the instruction from on high to automate tests because of a recent goal-setting meeting rather than it being a solution to a problem.

Considering our test tools as instruments lets us look at how tools can be used to help specific tasks - implement tools to solve problems (whilst understanding their limitations and flaws) rather than find tools to replace existing tasks for the sake of automating them.

This was a talk that is better than I can describe in a blog post. It really illuminated the power in a shift in perspective on tools rather than mitigating individual risks by patching them with automation tools.