Transition from Manual to Automation skills – Challenges and Solutions

Forces of Change
Let us start with the bigger picture. Humanity will go through a CHANGE whenever something can invent or discover that touched the commoner. It is valid for stone tools, agriculture, steam engines, and even democracy! The digital world is just another kid on the block who arrived recently.

Contextualizing Software and Testing
The driver chain can be simplified something as follows:
The digital world – Fast changing business – IT/Software to keep up with business – Automation is a key enabler – Test Automation is one of many automation. When the business gets disrupted, ways of doing business get tossed around, so the supporting software – app or product, has to catch up with speed. Test Automation is one key enabler for the software development process; methodologies and tools have been re-invented or modified for this speed.

want to know more about software testing courses visit Testleaf.

Intent
The first and foremost is that you have a serious intent to become an automation developer. You are committed to invest time, money, and effort to become one. You are likely to quit sooner than later if your intent is not severe or your commitment is weak.

I am… I want to be…
I am a non-automation (QA Tester or someone else), and I want to become an automation developer. The goal sounds simple, and what may not be directly visible to you from above is that you are boarding on a Transformation Journey.

Travel Time
In movies, transformations happen in a flash for our beloved heroes. Career role transformations occur over time, influenced by several factors. There are two key things.

1. The first one is known and easy to recognize. Duration to acquire the skill. Two-month or 6-weekend course, or a self-paced program that you plan to finish in 3 weekends.
2. The second one is ignored and lying there hidden. The duration took to achieve competency to call yourself confidently an “Automation Engineer.”

Allow 2 to 3 years duration, from ground zero to being a seasoned automation engineer/developer.

Becoming Technical
The role of an automation developer demands coding skills much more than “hello world!”. Here you have to come to terms with two realities –

1. You speak a language that you are very new to making a machine understand.
2. Psychologically, you may feel persistently nagged. Assure yourself that you are not dealing with a human and not your parents-in-law!

In my experience, I see most folks find this challenging, particularly those coming from a no-coding background. One good thing about this is that it is entirely within the reach and control of the individual. I suggest following a graded path of complexity in solving problems -implementing code.

Try snippets codes in the base programming language such as Java, C #, or TypeScript. The critical mantra here is to keep moving from simplest to complex ones, so the motivation does not drop to a level that you quit and say, “Hell! It is not my cup of tea!”.

To be specific, say you are doing in Java, start with printing hello world to basic conditional statements to looping statements rather than trying to solve problems with collections or implementing Java 8+ features. Here, your training mentor can influence you by guiding you along the route so that the journey does not feel too tedious and tiring.

Use it or lose it!
Here, a fitting analogy is you know how to drive; you demonstrated in an on-road test and got your DL. But are you a confident driver?

Automation skills you acquired would quickly fade away in your memory if you are not using them. In a practical sense, what this means is that if you can automate simple scenarios, say in Selenium, at the end of your training, you should get yourself into a selenium automation project in your org right away.

What if the opportunity could not give? Denial of opportunity can be encountered many times in our lives, which happens for 70+% of those completing a course. Here are a few things you can do very well and within your reach.

1. You do not need to be in the automation team to automate the test cases. Automate simple test cases, but that extra effort and stretch after your workday—a couple from the smoke test suite. Execute them consistently after your builds, fix problems with those scripts, and make them robust. Showcase that to your supervisor and then to your customer. Any reasonable manager or customer would open the gate for you in their automation team. Your second leg of the journey begins there.
2. Effectively use the cohort you were part of, where you studied the automation tool. If there were not one, form an interest group with a few and automate any available app in the public domain. Do not take more than a dozen scenarios and try a variety. Adhere to a timeline, say, two weeks or four weekends.
3. Never shy away from playing solo if the group is interested. Yes, it is a bit hard, but it also has some advantages. For instance, you can automate your monthly utility bill payment, and I assure you that you will feel rewarded!