On Testing Technocrats

The agile manifesto, written in 2001, states as one of its aims -

 "Individuals and interactions over processes and tools"

It is hard to imagine how in an agile team, where stakeholders, product managers, developers, testers, BAs and other groups work so closely together and much knowledge is tacit and undocumented, the above aim could possibly be ignored.

Software is ultimately used by people to implement solutions to problems people suffer from. It is created by people. The use cases and requirements that developers implement and testers test against are created by someone to reflect someone's (or some people's) wishes and needs. Testers test to find issues that we hope will never be discovered by people whose problems the software under test is built to solve.

...Which makes me annoyed about the idea that development/test teams can automate everything. The problems that bad software can cause for people are many and varied and the numbers and kinds of ways that a non-trivial application may fail are far greater, often more subjective than we can possibly plan for in advance. Requirements and specifications have subtle holes and areas of tacit knowledge that risk creating a product that does a wonderful job of something people don't actually want.

I am a big fan of test automation in its rightful place. As a regression tool it frees the tester from hours of tedious and often unfruitful checks to concentrate on those areas that require more exploration, analysis and thinking. It provides stubs and mocks so that the developer and tester can continue their work without the full integrated system being ready or available. It creates reams of test data of whatever attribute is necessary so that we can continue our work without laborious setup. It helps us perform checks with multitudes of simulated users to discern areas of poor performance. For all of the above however it doesn't replace the thinking mind of a competent test analyst. The kind who is adept at putting him or herself in the frame of the user, with all the complexities this involves.

But some of us feel that we can automate all of this away for 100% test coverage by automation, or that some future AI will make all non-automated test approaches redundant (not convinced that this will ever happen). I wonder, is it all about cost-cutting? The bottom line?

Or is there a type of person who thinks that the ambiguous and complex can be completely reduced to a set of checks and algorithms? That the human dimension, the outlook that human beings provide, can be abstracted away by technology? That what people see as quality can be reduced to a set of Yes and No answers. We hit the button, stand back and like the great tech sausage factory, we pump something in, our list of deviations comes out. Rinse and repeat with a few fixes and we get quality at the end...

I call these types the testing technocrats. By reducing our work to purely algorithms and checks to be done by machines - and quashing the thinking factor - they reduce the wishes and concerns of the users of our products to exactly that.

All in the hope of getting releases out faster, saving a bit of money and not to have to deal with the complex findings that a thinking human tester provides. This has been called out as wrong many times but often to deaf ears.

Test automation is an amazing thing that lets us achieve great efficiencies. It is not a replacement for the thinking human element. As testers we should be taking every effort to continue argue against those who believe it is.