Blog Details

Testing Parliament

Personal Shift to Test Automation

Software testing is a profession that has the ability to pique the interest of various individuals from different walks of life even people who don’t have mainstream IT qualification. When we talk about making a shift to test automation the background of the person trying to make a switch is important, secondly, the reason they want to make that switch and thirdly, what resources are at your disposal to make the switch. A lot of articles have been written with regards to making a shift to test automation but most of them give a nudge to an organization as a whole, not an individual which leaves a lot of questions unanswered. The organization offers time, money and training for the switch.At a personal capacity, it is going to be quite challenging to attain the three constraints evenly. The idea is to try to paint a picture of how to make it into test automation against all odds.

  1. What background do you come from?

People who find it easier to get a job in test automation are developers, there is no doubt about that. It is often seen as a downgrade from a developers’ perspective to join testing since it is seen as a lesser role. The focus will be on individuals with zero programming background or little from varsity. The first barrier to test automation is the programming language, besides having a tough time deciding which programming language to learn there is still that issue of finding the time to practice it. The second barrier is when you are at the pinnacle of your career as a test analyst and your rate is a bit higher than that of junior test automation engineers. The internal battle for senior Test analyst is that, should they hang on and break through to test management layer or switch. Although they might have the funds to take themselves to formal test automation training the issue is creating an opportunity to use what they learned.There are a lot of test analysts with formal test automation training gathering dust. My take on that one is

Use it or loose it

Whatever Background you come from, the idea is to decide and just start. A day has 24 hours in it, surely one can find an hour or two somewhere in there to dedicate to this task.If you don’t have any programming background more than two hours is recommended, in addition to that would be finding a mentor.

2. Why you want to switch

This is the most crucial factor to any change in any either your professional career or personal life.When you want to quit halfway this reason will be the one to remind you why you started in the first place. There are few reasons why one would want to switch to test automation.

  • For survival
  • For career opportunities
  • Manual testing is boring
  • For better pay

For survival: if your employer is adopting a new development approach like DevOps and the need for test automation is for job preservation then tough luck. I hope you never join test automation under these rude awakening circumstances likened to the time of  P.W Botha, Adapt or die. These choices lead to two extremely polarised outcomes make it or break it scenario. There was once a rich man who liked hosting games to entertain himself. One of the games was to wrestle an alligator he owned and win a sports car of your choice, a mansion and 1million. Before the game could start there was a contender in the pool wrestling the alligator before the terms and conditions of the win could be explained. After the fight was done and the poor animal was lying there lifeless, everybody was cheering for the gallant winner. When the rich man was about to ask him to choose his car the guy said: “I don’t want any of this”.   Everyone was shocked by his answer, the rich man was a bit curious and he asked him what do you want my good man. his reply was,”An idiot who pushed me into the pool”, still panting.The point here is, even if you make it as an Automator because of this motivation you will still have that little resentment to the craft because it was imposed on you.

For Career Opportunities: If your eager to learn test automation is to increase your chance of employment there is hope for you because they change is voluntary, unlike the prior mentioned reason.  The advantage of this decision is that the individual can self-pace how they embark on learning the test automation skill.The epiphany of the need for this change was internal thus makes this person more likely to persist even when the going gets tough.The learning starts with an end goal in mind.

Manual Testing is Boring: Embarking on test automation because you think manual testing is boring seems like a good idea for an individual looking for a challenge however if something interesting comes along this endeavor will be dropped at a drop of a hat. Any task will seem boring after you have mastered it to some extent. if something bores you innovate because I can assure you, coding is not for the faint-hearted.

For better pay: Anything that you do not out of passion will feel like a job more and more every day and at some point, the money won’t be worth it. There is a  lot of people who enter the fear factor challenge for money but few fail to see the whole thing through. No matter how much you think you earn sooner or later you are going to adjust your lifestyle to suit that package. Although this beats crappy pay, it is recommended that you find what you love about test automation pronto.

Whatever reason that gave you an urge to want to join the test automation that is your own prerogative.From my personal experience, I made a switch after being given 6 months to try test automation or continue as a software developer if  I found it less challenging. I finally made a switch because of the following reasons.

  • For the love of programming(believe it or not it is fun)
  • It  pays as well ($$$)
  • It allows more room for creativity
  • For the love of challenges (Brain-Teasers)
  • Machines are easier to deal with than people.

Now that you have reached this point what is the next step. It is going to be difficult to cover all starting point for everyone, as a result, I will focus from a point of a manual tester making the transition. There are few actions that will assist you in your quest to become a test automation engineer.

  1. Take the initiative.
  2. Learn the tool already in use.
  3. Get a mentor.
  4. Learn the language behind the tool.
  5. Practice, Practice, Practice.
  6. Go through the Cold Cases.
  7. Explore other tools.
  8. Learn how to write a framework.

 

  1. Take the Initiative

Matured test team have test automation teams in place, ask for an opportunity to run some of their regression pack that they dread to execute and maintain. Learn how test data is prepared for test automation scripts. Adding an hour after your eight-hour tasks or before is a must. It can not be business as usual.

“If you want something you never had, you must be willing to do something you have never done”. . . . Thomas Jefferson

2. Learn the tool Already in use.

Go ask for the tool being used to be set up on your machine. If the response you get is that they only have a finite number of seat licenses, request to use them after hours if need be. Whatever arrangement you bargained for as long as it does not hamper the productivity of the team they will be unreasonable to shut the door in your face. Go through the user manuals that come with the tool and ask questions as you go through the documentation.

3. Get a Mentor.

To get a mentor will be much easier if you have started something from your side. it is human nature to try to help a person who is already trying something. Deep down most programmers in their hearts wish to be mentors they never had. Complete the task set out to avoid demoralizing your mentor or creating a perception that your endeavor was decided on a whim.

4. Learn the Language Behind the tool.

Every test automation tool has a programming language that complements it.  Micro Focus UFT has VBScript, ShellScripting, and  C Sharp supplementing it. Selenium Webdriver has Java, C Sharp, Python, Ruby, and JavaScript. WATIR(Pronounced water) stands for Web Application Testing in Ruby and yes you have guessed it uses ruby. At the beginning, it is not a must to learn the language but if you want to reach a level where you create complex frameworks, recording and replay alone won’t get you there and your test scripts will always be as flaky as ever.

5. Practice, Practice, Practice,  Practice.

For athletes, that’s all they need to do to get to the world-class level. There is a 10 000 hour rule that suggests that upon practicing a certain skill for those hours you will become efficient in it. Playing tennis, golf, soccer, piano, and boxing to name a few it does apply to some extent because over the years those field has seen minimal change in rules or tools. I am afraid in test automation is about learning, unlearning and relearning. When you think you are the best the tool changes and now everyone is a newbie. Although you will be having an advantage because you have been in the game for a while. Be careful of being dependent on a particular tool but learn test automation as a skill.

6. Go through cold cases.

After some time of completing use case scenarios set up by your mentor or creating dummy scripts based on the various web applications. Request the proof of concept documents for those projects that were flagged as not automatable or lost cause. The reason they were canned might be because at the time there was no technology or skill to handle the request. You won’t be holding the team back with their delivery of the business value-add projects. Solving such project will gain you recognition and a seat at the table.

7. Explore Other tools

Whether if you want commercial tools or open source tools it’s up to you. I recommend mixing the flavors of one commercial and one open source. Commercial tools will be based on 30 days or whatever days they offer as such learning two commercial tools concurrently might not be fruitful. Exploring other tools will give you the opportunity to understand the shortcomings or each tool and their advantages, as a result, you will know which situation is suited to use which tool.

8. Learn How to write a framework.

The test automation frameworks have evolved throughout the years. The first generation is the record and playback which is easy to learn and also hard to reuse. The second generation is the modular scripting which employs the use of functions and libraries. The third generation is a framework that incorporates modular scripting as well as adding a level of abstraction by introducing parameterization to drive the test using data hence data-driven framework. The fourth generation framework refers to the use of keywords to invoke action related to those keywords. The fifth generation is called the hybrid which combines both keyword and data-driven approach. The sixth generation is a bit elusive to create, it is called the codeless scripting framework which lets business creates the scenario without any knowledge of the code. HP Business process testing tries to achieve that.  Tools like  Ranorex, and Katalon promotes such frameworks which are business oriented. See the image below that depict what has been explained.

Test Automation Frameworks generations

There were other frameworks that did not last long or did not gain as much popularity as the ones mentioned above like model-based test automation framework used by Tricentis tools like Tosca.
It is no brainer that the latest generation of frameworks is the ones to learn in detail. I wish you the best on your journey to test automation and be warned that now the learning never stops.

 

Leave a Reply

Your email address will not be published.