Paul Gerrard

First published 10/05/2016

Some Labels are Bad, Get Over It

There's been a thoughtful debate on the notion of 'test automation' being a rather bad, lazy, misrepresentation as a concept or entity or thing. James Bach and Michael Bolton wrote a paper here. Alan Richardson, in Testing Circus Magazine invites you to join the Anti Test-Automation Brigade. Pretty much, I agree with the sentiments expressed. The term is bad, it exhibits and probably promotes muddled thinking. I will do my best not to use it. Unless I need to reference the range of tools that dominate the testng tools market.

I'll return to this a bit later.

My Dad called himself an engineer (or rather, his company did). In his national service, he joined the Royal Engineers and was very proud of his time in the post-war, peacetime Army. He told me that he spent much of his time going on training courses. When offered the choice of a course on "4.5 ton truck engine maintenance" or two weeks tramping around muddy fields in Germany, unlike many of his comrades who preferred the mud to a classroom or workshop, he chose the courses.

He also did real some engineering - building and dismantling bridges, towing tanks out of ditches and other hearty activities. (Once a tank was bogged down near a churchyard. Dad's idea was to pass a cable around the church to improve the towing angle on the cable. When the recovery truck pulled, the tank was unmoved, but the church started to disintigrate. They stopped the truck and figured out another way to extract the tank, leaving the church intact to great relief). And so on.

So when the time came to selecting a course at university - an engineering degree was the natural choice for me. I thought I would be part of a select, engineering elite. Yes, there were civil, electrical and mechanical engineers, but they were all a happy and respected band of professionals. Then I worked at a large civil engineering consultancy. Everyone was an engineer. And then I noticed, half the male population called themselves engineers of one sort or another. When I got into the software business, I discovered some software people also called themselves engineers. This was a step too far.

Now, my main criteria for the definition of an engineer is someone who works with concepts, designs or materials whose behaviour are underpinned by the laws of physics. Software, in my humble opinion, does not obey any laws of Physics that I know - so it is not an engineering discipline. Discuss. At any rate, it seems nowadays that anyone can call themselves an engineer. Raging against this calumny seems not to be a good use of my time.

The testing tool vendors are not about to change their marketing and rename all their tools on the basis of complaints from a few vociferous individuals. So I suspect we are stuck with the Test automation term for the foreseeable future. I support the view that test automation is a lousy term, but I don't thnk I'm going to get excited about removing or replacing it.

However.

A Bad Term, Well-Scoped?

The view that test automation does not encompass support for all of testing is obvious and if test automation does have a scope, it covers the application of tests (or checks). Some tools can perform logging and reporting, possibly, but let me ignore that for the moment. I am using the teminology of the New Model below.

Let me suggest test automation refers to the 'Applying' activity only. If you add in other utilities that come under the banner of  "testing with tool support" - these utilities mostly fall into the Applying aspect of testing. Building environments, preparing test data, generating combinations, analysing results, editors, comparators, analysers, harnesses, frameworks, loggers, cleaner-uppers and tear-downers and so on are all pretty much covered by the Applying activity. So if test automation represents the Applying activity only, it may not be well named, but it could at least be well-scoped.

Perhaps we should rename Test Automation ... Test Application? Or just Application?

More importantly, the nine other activities in the New Model plus the judgements of model adequacy or inadequacy hardly get a mention in the argument which ignores the opportunities to support thinking, collaboration, modelling, test design, record-keeping and so on.

We Need to Curb Our Enthusiasm (or Addiction)

It seems to me that the testing industry - both testers and vendors - are obsessed with test automation to the degree that (with some exceptions) testers are not demanding product to support exploration and modelling activities on the left hand side of the New Model and vendors are not investing in R&D. There are signs this is changing but it has been a slow process so far. Supporting these activities could bring huge benefits to testers. The market for these tools (required by all testers possibly) is also huge. Why are test design tools not being demanded and delivered?

If we label all test tools test automation, it take our eyes of the real prize - tools to support all of testing. Testers and vendors need a broader perspective. 

I've been banging on about wanting Test Design tools rather than Test Execution tools for some time. I dug out a talk of 1999 which I gave several times including a variation at STAR East 1999. I am quite pleased - maybe 75% could be repeated today without embarrassment. But I am also rather depressed that I am making almost identical recommendaitons nearly sixteen years later. Click on the image or here to see the slides.

What am I Doing About This?

Firstly, you may know I am working to create a comprehensive tools directory at https://tkbase.com - it covers DevOps, Collaboration and Testing and there are not ten or twenty tool types - there are over 180 tool types with 2414 tools listed.

Second, I am writing a paper on the applicaiton of automation AI and Deep Learning to support the other (exploration, thinking, collaboration and record keeping) activities of testing.

Finally, for the last few months, I've been writing and experimenting with a robot that supports exploration and testing - exploratory testing - if you like. It will support team exploration, pair testing and can also be voice controlled. I'll have something to demonstrate in the next month or so. I'll be talking about experiences with this more fully later in the year. If you are interested in being a pre-alpha tester - do get in touch :O)

What are you doing to further the case for tools that support all of testing?

Tags: #engineers #Testautomation.NewModelTesting

Paul Gerrard My linkedin profile is here My Mastodon Account