Automation – The Journey to Create a Test Case
A Quest to Learn Software Testing’s Great Potential, by Will Collett
Few have not heard of the concept of automation, and many have formed some kind of opinion on the matter. In the 1993 film “Jurassic Park,” automation is depicted as not only one of the triumphs, but a major contributor to the downfall of the eponymous park, in addition to the rampaging dinosaurs. In many cases, automation has become synonymous with robots, from the industrial real world robots that build our cars to other popular culture Science Fiction icons such as Isaac Asimov’s famous “Laws of Robotics” and Westworld’s Host androids. However, automation is more than just industrial applications and Sci-Fi plot devices. Today, I’m not talking about automation in regard to robots or theme parks, but one of its less popularized forms: Automation Testing.
Automation testing in Software development is the process by which a programmer, often called an Automation Engineer, executes test cases via a program rather than manually testing the software. A prevailing opinion is that automation testing is better than manual testing. While it is true that the actual testing process is faster, there are still weaknesses in the automation testing process. The automation code is only as effective as the programmer who created the code, and in order for the process to be effective, the information returned by the program needs to be manually scanned by the engineer. The code also requires maintenance given that a website’s entire source code could be rewritten between builds and thus making the original automation program worthless until it has been updated. These issues, while minor themselves, can compound the process to make automation only slightly faster than manual testing, if at all. Coupled with the fact that automation runs are incapable of performing look-and-feel and ad-hoc testing, a good test plan incorporates both automation and manual testing, rather than sacrificing one for the other. Automation can free up the static exhaustive regression testing, allowing the manual testers to investigate issues off the beaten path.
Given this fact, industry practice often prefers testers to have at least a basic understanding of how automation works. Likewise, the best Automation Engineers have a strong background in manual testing to complement their programming. There are a variety of automation tools on the market available for users to experiment with, from Firefox plugins that record and playback user inputs, to full webdriver suites requiring programming knowledge. In today’s market, the open source web driver, Selenium, is one of the most popular and is favored among both beginner and experienced testers.
Shortly after my eyes were opened to testing in the MindSpark Training, I began researching the types of careers open to software testers. A common skill many of the job openings mentioned was some experience in Selenium, which I had never heard of at the time. A basic google search informed me that Selenium was an automation tool. I’d been taught a little about automation testing before, but I was so new to the subject matter that I put the knowledge away for later. A few weeks later, the instructor began gauging each of our skills to determine the projects he might recommend us for when we completed the training. He asked if any of us had programming experience. Recalling my two years in college during which I’d majored in Computer Science, I said I had some Java experience, but was very rusty. He asked if I had heard of Selenium and challenged me to learn the software.
My first hurdle involved setting up the software. Selenium is not a standalone program, rather it is more of a library of functions that must be called through a compiling program. Some research was spent looking at various popular IDEs (Integrated Development Environments) to use in conjunction with Selenium, ultimately settling upon using the Eclipse software. However, another issue manifested. None of my setup codes seemed to work. Unbeknownst to me at the time, Selenium 3.0 had been heavily updated and optimized from Version 2.0, rendering most selenium tutorials created before 2017 out of date and almost completely worthless. Unaware of this, I became frustrated with my lack of progress. With no pressing issues requiring me to learn the tool, I set it aside to work on “later”.
For me, “later” and “never” are unfortunately very similar. Eclipse sat on my desktop for several months, and progress reviews reminded me that this goal to learn Selenium was ever-present. During a bout of frustration involving one of my other jobs, I sat awake one night with my phone looking up testing career paths. One article that caught my attention directed me to a freelancer site which promoted training and tutorials for people interested in software testing skills. Discovering that there was indeed a tutorial for Selenium, I attempted to give the process another shot.
Unfortunately, this new tutorial was also out of date, but it managed to get me along enough in the process for me to discover this fact. I discovered a newer tutorial online that was geared specifically toward the new version, and the drivers necessary to open the web browsers. Now I needed an appropriate test to practice on. I decided to start with something simple. Logging in and out of a test website, and from there I would branch out the demonstration. Unfortunately, my choice of website was poorly made. I had initially chosen the site because the login page was relatively well coded and the process of logging in was a simple one to automate.
Logging back out was another matter entirely. The site in question features no less than three information pop-up boxes which open upon log in, and must be parsed in order to even access the log out function. Pop-ups, which I had not realized at the time, are difficult to handle even for experienced automators, and in my excitement I had already locked in a hard deadline to present the functional test to the MindSpark Automation Lead in only a few days. It took nearly 48 hours in order to solve all three pop-up boxes, and some time to figure out the command to log out of the site, and before I knew it my time was up. All these hours had produced a script that ran for a grand total of about a single minute and logged into a site, closed three pop-ups, and logged out. I had not had time to update the code to do anything else and I bemoaned the fact that this code was embarrassingly simple. I added in some time delays to show off the pop-ups and braced myself.
Our automation expert was quiet as my code ran, linking to the site, logging in, closing the pop-ups, and then logging out. He asked to see the code, to which I obliged, and then he finally said “It only took you a few days to get past the pop-ups?” It was then I learned the truth about the pop-ups. Deceptively difficult to master, it surprised him that a novice had managed to tackle three in one program without coming to him for help.
Automation is a fascinating skill once you come to understand its potential. There’s something almost magical about writing code and watching the computer interpret that code into a result. I’m excited to continue learning automation and hone what I learned into more effective methodologies. Musha, our excellent automation lead, is already directing me with research to learn about compartmentalizing testing commands and writing dynamic xpath locators, and other more advanced techniques. I’ve also been assisting my coworkers take their first steps into this great opportunity. With more of our clients seeking automation solutions for their products, this truly is an exciting time to learn this amazing skill.