Where to start to automate your checks?

So you are an almost only off-shore tester on a project, and want to automate some of your daily checks to have more time for actual testing. But you lack skills to do it right, or you think you do. And the automation tools and frameworks do not suddenly appear in a project. Somebody needs to implement them.


This picture is familiar to lots of us. But how can we push the deal out of this vicious circle? If not directly to a project's but for self-development sake?

We often hear the management saying: “We do not need automation at this point.”
And they are right!
They do not need an automation of those checks YOU PROPOSED, if it is done by YOU INSTEAD of the work you are hired for, especially in that weedy way YOU NOW would do it.
Whole disadvantage from their perspective!


Starting to write code is always hard and slow at the beginning, because the code quality is in direct proportion to an amount of hours one spent attentively staring at it. So here I propose the first points to look at start:



1. API, for web-based projects aka “Back-end”

• This is not hard, as there is only code-to-code communication. Without UI, CSS locators and other AJAXes. (Smile and say “See you later!” to those who've started with Selenium at once.)

• This is smart, because the API is changed far less often than the UI.

• This is prosperous! Have you seen in the Software Tester's Position requirements an abbreviation like REST, SOAP, XML, JSON? This why! An ability to easily de-serialize JSON object with any programming language is well paid now!

2. Business-critical stuff
If you have already got a clue in automation, you must try to “sell” your skills to your employer! Show them some working example on how the automated control saves money/time. You can tell some stories for hundreds of times, but people rarely think about something not touching them directly.
Find a thing that brakes most often, and write some scripted checks to monitor its state. To know about next time it's not working as early as possible. A good tester should always be able to identify the bottlenecks in the development phase and monitor them.

3. The things that do not change (often)
You have already covered with auto-checks all the previous points, and only then, you may start with UI. Find something that least probably will be changed. That is, the most stable and unchangeable part/feature.

You may ask:
Why to check something that is never breaking?
Opposite question:
How much will the project suffer if something “not breakable” once breaks?

The first question indirectly implies that you cannot have innumerous checks at a limited time, that a check costs time and  money. This is definitely right. For manual checks. But the cost of automated check compared to a manual one tends to zero.

And the more often we run an automated check, the less becomes its relative cost for us.

4. All you think worth automating
Many begin their automation from this point. And fail. Because your priorities and expectations very often differ from customer's ones, regardless the tester should “think like a business do”.
Managers look at your weak attempts to do something they don't think is important, and that possibly might have value in an indefinite future...
And then we hear: “We do not need automation...”

To sum it up, you need:
 - to write the code good enough to complete things you think are useful, so train on API;
 - to find checks that the business would value;
 - to widen and complicate your checks along with your business knowledge and your skills.
 

PS Thanks for ideas to
Michael Bolton ‏@michaelbolton,
James Marcus Bach @jamesmarcusbach,

Gerald Weinberg @JerryWeinberg