So, you’ve decided that it is time to make the transition from Manual Tester to Automation Tester! After reading the want ads, the technical push is obvious – more SQL, more automation testing tools, more acronyms that you need to look up, and you feel left behind. Your current job is jumping between short-term gigs, manual testing somewhere that you want to leave, or you are “in between”. You’ve talked to headhunters who sigh when you say you want to stay in QA but don’t have automation in your skill set. You ask if anyone will hire you and let you learn on-the-job, and they sigh again, before whittling their list down to “OK, here’s what I have where you can start as a manual tester.”
Falling behind the times is a bad habit. Like any bad habit, the path to success requires committing to change, pushing through each day until you internalize that change, and the change becomes who you are. If you work at a place you hate, see if they’ll pay for a class and wait it out. Pay for it yourself if you have to. Ask people you work with for advice on gaining the skills you need. Buy a book. Watch a YouTube video. Take a free class online. Learn SQL, but do more than a one line query. Learn programming languages. Find out what they use at work, learn it, and use it. See if the Bug Tracking System you already use has examples of actual code fixes and study them. If your company gives you access to the source code, start taking a look there. Start looking at the source of web pages too. Understand that reading and writing code is part of the required new skill set.
If you’ve never done any programming before, you may want to start by doing UI automation that is record/playback (no programming required). Then, start playing with what got recording (programming involves writing stuff then seeing what happens when you try to execute it). You may begin with removing or lengthening sleeps (all those pauses between actions when you made the recording), or changing input text, or repeating a mouse pick. The concept is that each line makes something happen, and that changing the parts therefore change what will happen, and that you can be the master of what happens. Mess up a command word or punctuation (in this case on purpose), and you get a syntax error – a warning that you cannot run this.
After you feel comfortable with record/playback, the more sophisticated way to automate is keyword-driven. This means that you can directly address elements on the screen, like select the third item in the Country dropdown, or check the pointsize, font and hex color of a particular label against their expected values. Like playback/record, keyword-driven just checks what it is told to do. It will never say “those colors clash” or “things are too close together”. And if the test script works fine today, it will not know that when the Expected changes a year from now, that this test script will need to know those new expectations. But these are known limitations, and with good record-keeping, we should be able to maintain regression tests made this way.
But I’ve digressed. The point here is that you need to dive in and gets your hands dirty by actually doing coding. Get yourself a free language (AutoIT, Selenium, Appium, Cucumber, Marathon, Robotium, Sahi, SoapUI, Watir, etc.) and start writing now. Use it at your place of work, volunteer somewhere and use it, throw it into your consulting work (as a self-check, but it can go on your resume now), or join a crowdtesting community and use it there. My point is that you need to use it once you’ve learned it. Get comfortable with it. Get excited about it. Be ready to talk too much about it.
Your manual testing knowledge is still a healthy base on which to build, not info to be tossed out and replaced by your new coding skills. You still need to come up with appropriate scenarios (maybe inappropriate ones too!), determine the necessary steps, and figure out the scenario variables. But now, you’ll be able to implement the actual testing in a different way. Write once, execute quickly whenever. There will be nothing vague in your steps – everything is precise and will be done exactly as you have specified. No wasted time having a human read, comprehend then execute each step and check the expected result.
Author Bio:
Scott Andery is an expert marketer and author who specialize in software testing tools and resources.