Total automation with sellotape and glue

Luckily for all of us every profession evolves, and test automation is no exception. What I can see is test automation is now more affordable, and is done in a more professional way than before.

Same goes for approaches and tools (and for those who still trust Internet more than their own judgement, some gurus have already posted a very good knock out article leaving losers like myself with a tingling feeling of guilt for being too slow to update the blog).

But there's still another subject I would like to speak about. It concerns the approach to automation in general. Actually, it intends to slightly shift the way we understand automation and targets some of the popular stereotypes in attempt to get rid of them.

Here goes a brief disclaimer. I worked for companies with very different professional levels, cultures and budgets. These three, in their turn, affected companies approach to automation a great deal. Being a summary of those experiences (and some of those experiences have come a very long way to get here), it is very possible that the content of this postwill seem too obvious for some people.

However, judging by the fact that people still keep stepping on banana skins, I hope someone may find it useful.

What's automation anyway?

It's is an instrument which goal is to make your life easier by relieving you of time-consuming (sometimes also rarely-changing) otherwise manual activities. Traditional understanding of test automation implies that you pass the task of 'imitating a user' over to some kind of a robot. Robot may be imitating a human, if we are dealing with frontend scenarios. Or it may pretend to be another piece of  software if we are dealing with back-end automation.

But should we limit ourselves with automation of a workflow only? After all, the ultimate goal of automation is to save our effort, not to stick with certain approaches or tools. So here are some other examples where automation can be applied:

-- partial workflow automation (you may not have time or opportunity to automate the whole thing, but you can still automate some of it by means of record-and-play tools);

-- generating test data (passwords, usernames, request body etc);

-- test data analysis (write a simple file reader and make it analyse your heap of files; personally, I once created a Goldberg machine out of SoapUi + Groovy script + excel-compatible csv export, which looked absolutely uncool, but worked like a charm, quickly and reliably);

-- bulk update of large amounts of text files (in the dark hour of my professional life I once had to update namespaces in 600+ XML responses in 30 min flat by means of a simple script based on sed);

-- generating reports (I colleage of mine hacked into xlsx, updated it with a script using JIRA API and packed everything back again);

-- automated data analysing (formulas and pivot tables in excel work magic when it comes to collecting simple statistics, estimates and team capacity; once, I even created a Gantt with Excel bar chart).

All of the examples solved the targeted problems, and were extremely cheap to use and maintain, which, in my opinion, is a requirement for a good automation.

I'm sure this list is far from being complete.

Fancy tools vs sellotape and glue

Things like test pyramid are nice things if budget owners are into problem prevention and strategic thinking. Same goes for three-letter things like TDD and DDD. Unfortunately, good management is not always the available when it is needed. Although, it is still an open question if you need to save asses of people who don't seem to grasp an idea of investing resource to get more resource, if you find yourself assigned to such a project, you may need to make friends with sellotape and glue. And it not always a bad thing, to be completely honest.

Some psychological aspects of test automation

Not sure about today, but some ten years ago test automation was synonymous to Java automation and was seen by a majority of salary-bound losers like myself to be a tricky narrow way into Java programming. And from Java programming to working from somewhere else but office, preferably from Goa. Since then Goa went out of fashion which cannot be too bad.

In conflict management they say you need to see a problem as an iceberg, and do not stick with an above water part only. Same can be applied to test automation. Behind the powerfull cliches (sometimes enforced by references to gurus) there are the usual needs and pains of humans who are trying to do Maslow's survival and self-actualizing in one go. 

Deep waters

If we look under water we may see
-- a parent-child relationship between a tester and piece of software they managed to create (and no matter how modest the result is, the emotional investment of a hard work is always the strongest);
-- a dream to radically change your life to something more free, more peaceful, or more challenging and daring; 

-- a collaboration issue when picking a solution is a bit more than just picking a solution, but a fight for what it designates for a give person.

Following the same logic some tools and approaches may be rejected for simply not being cool enough and not leading directly to Goa. Not because they do not serve their purpose.

A conflict of interests like this is almost always harmful to the project and needs to be addressed with attention and care.