Switching careers in QA: From manual to automated testing

Are you a manual tester? Are you attempting to switch careers in the software testing industry? Are you trying to break into automation development?

In this article, I will outline how I made the transition from being a manual quality assurance engineer—a technical position that deals with next to no actual coding—to an automated testing position, where I am programming in Selenium and Java daily.

This transition didn’t come overnight. It took years to lay the groundwork for this career shift. Because I found the transition difficult, I’d like to share some pointers with other software testers who are in a similar situation in order to make their career shift easier than mine was.

Get the Free Course to switching your career at Katalon Academy!

Recognizing the changing industry

I have been part of the software testing industry since the dot-coms first started roaming the earth, and for most of my career, it has been pretty much the same. My job as a software tester has always been to act as an end-user advocate. I provide a voice for customers of the web application that I am testing. After distilling both the product requirements and the user interface design into test cases, I execute them as a manual tester, using the same tools our customers will use: a keyboard, a mouse, or fingers on a touchscreen.

Manual testing, I found, is still the best method when testing brand-new functionality. But this quickly becomes tedious for the tester when you’re regression testing—checking to see if code changes didn’t break the old, working functionality. Verifying that everything in the web application still works in Chrome, Firefox, Microsoft Edge, IE11, IE10, and IE8 is an exercise in frustration. If the thought of executing a particular test case causes the QA team to gnash its collective teeth, that test case is an excellent candidate for automation.

Back in the old days, automating the browser test suite was an expensive process. Companies wishing to automate browser testing purchased expensive software packages such as Rational Rose, the Mercury Toolset, or Segue Software’s Silk Test, and all the costly training sessions that go along with them. This has changed with the popularization of Selenium WebDriver, a free, open-source library that can be used with Java, Python, or Ruby. This library simulates a user pressing buttons, entering text into textboxes, and selecting web elements.

This tool has one unpleasant side effect for the software testing industry: New requirements were added to software testing positions. For the first time, software testers were required to know how to code.

The agile software development process also changed the life of a software tester. The relationship between development and QA shouldn’t be the same as the relationship between an artist and an art critic. It should be more like the relationship between a writer and a copy editor, both applying their specialized skill sets to make a quality product. Instead of being a team apart, software testers were becoming fully integrated with the development team, working hand-in-hand, charting what they as a team could accomplish every two weeks.

But where did testers need to put regression testing in an agile workflow? Should there be a one- or two-week regression testing sprint tacked onto the schedule, run just before the product is released to production? With the advent of continuous integration tools such as Jenkins, the automated regression test suite can always be running, doing everything from providing a sanity check when developers first merge their code to running against the full test suite just before it goes out the door. But this has put even more pressure on the QA department to learn how to code.

Make the commitment to learn coding

I have to admit that, at first, I was resistant to learning automation. I had spent over 15 years becoming well versed in software testing. Why would I choose to be a novice again? Couldn’t I just keep on finding jobs that tested software in the same old way I already knew?

When I found myself on the wrong end of a layoff two years ago and I was back to interviewing, I found that it was becoming harder and harder to find positions for which I was qualified. I’d make it through the phone screen. I would make it through a few rounds of face-to-face interviews. In the end, I found, more often than not, that I was told that although the position was originally supposed to be “no previous programming experience necessary,” the job requirements had evolved with the needs of the company.

To stay in the software testing industry, I decided that I was going to have to really make a major time commitment to train myself in the new tools and technology. Making this transition would require serious time and effort, and I had to use my support network of family and friends to motivate me to do it.

For months, I would spend evenings and weekends locked away in front of the computer doing research and training. Instead of bouncing around Boston with my wife or going to whatever spur-of-the-moment fun and nerdy activity my friends were doing, I would be sifting through technical manuals and researching on the computer about automated testing.

Recognize that earning degrees is just the first step

I had spent so much time and effort earning a BSCS back in 1998 and a master’s of software engineering in 2008 that it was baffling to me that the degrees I earned were not enough.

What I did not understand was that earning the degrees was only the first step toward making a transition to a career in automation development. Software companies were already spending a lot of time and effort attempting to transition their own software testing departments. Hands-on, current experience mattered more than technologies that were studied almost ten years ago.

It wasn’t just the software testing industry. Even the programming language I was using, Java, had changed since my previous coursework. I had to do some serious catch-up work.

Practice like crazy

I discovered Alan Richardson’s online course, Selenium 2: WebDriver Basics with Java, a year before my last big job search. Alan has a knack for explaining complex problems simply, breaking things down step by step. The short lectures not only covered the basics, but also included all the intermediate and advanced material you could ever want, walking the student through installing Selenium WebDriver, Java, and IntelliJ IDEA.

My problem was that I found myself merely watching and listening to the lectures. Because I was not typing out the exercises side by side with the instructor, playing with and figuring out the code, nothing was really sticking, so I became frustrated and gave up after a few months of work. It wasn’t until I started working with Zed Shaw’s Learning Python the Hard Way a year later that it became easier for me. In order to learn to code, I can’t passively listen to someone describe his or her code. I need to type out the code, experiment with it, and refactor it; only then can I truly understand it.

Writers don’t learn how to write by only reading Strunk & White’s The Elements of Style. They learn by writing papers, essays, and articles, and they practice writing daily with journals. Coders learn to code by going beyond the classroom, experimenting on their own with writing programs and apps. Automated testers do the same with random sites on the web: How would I test this web page, and what tests would I write?

I’ve gotten into the habit of spending at least an hour a day coding, either in Python, Java, or Selenium with Java. The bad stuff remains buried on my hard drive. The okay stuff I post in my programming portfolio on GitHub. The important part is to keep working at it and improving.

Network like crazy

Meetup.com isn’t just for social activities. Type in search keywords such as “WebDriver,” “software,” and “Java” to find lectures, training sessions, and technical networking events in your area. Technology is always changing, and it’s very easy to forget that fact if you have been at the same job for a while. Meetups aren’t just a good way to keep abreast of what’s happening with the software industry. It’s also a good way to meet people who are also trying to keep up with industry trends. I try to go to one Meetup a month.

For networking, LinkedIn.com has also helped me. It’s a good way to keep in touch with your contacts: alumni of your alma mater, your friends, your current and former co-workers, and your former supervisors. It has allowed me to keep track of friends from former workplaces, see what projects they are working on now, and stay connected with them. It also allows me to review the background of anyone who has granted me an interview. When I have a job interview that includes a great conversation with the interviewer, that person becomes a potential contact, even though I may not get the position.

Recognize opportunities when you see them

When I first auditioned for my current position at Fitbit, it was pitched to me by the company’s in-house recruiter as a manual testing position. Fitbit needed someone to help build out its QA department, creating policy and procedure. It did have an automated testing department, but there were no immediate openings at that time. My main focus would be satisfying the company’s immediate manual testing needs, but I could get a bit of experience in automation from the automation lead. Would I still be interested? If so, Fitbit would set up a phone interview.

I had to think about it for a bit. I knew that I needed to figure out automated testing in order to continue my career. I researched Fitbit online and discovered that it was a great company to work for. I mentioned to the recruiter that I was looking for exposure to automated testing. Would it be possible to have maybe 20 percent of the job involve getting exposure to automated testing? She passed the information along to the hiring manager.

With all the homework I had completed, I was able during the job interview to speak intelligently about automation. I was able to talk about what automation is and is not good for. And I had sample programs I could demonstrate on my GitHub account. After the interview process, another candidate was hired to build out the manual QA team, and I was brought on board to develop automation.

Fitbit is a great company, and I am really lucky to be here, but if I hadn’t performed all of the prep work—making the commitment, going beyond what was learned in the classroom, practicing automated testing  a little each day, networking, and being open-minded about opportunities—I never would have been hired.

If you are in the software testing field and are trying to make the switch from a manual testing role to something in automation, don’t give up! It is going to take a lot of time and effort, but it will be well worth it, giving you a fresh new look at the field you enjoy.

Source: Switching careers in QA by T.J. Maher – Automation Developer