A Day in the Life of an Automation Engineer

TL;DR: taught a workshop and it went great. planned as a Selenium workshop but morphed into a broader automation workshop. presents practical use of automation over simplistic unrealistic intro; raving reviews from attendees.

As continuous integration is becoming more of a reality at the company that I work for, the need for automation is becoming more apparent. It’s definitely become one of our key themes, and quite frankly, a bit of concern for our testers who don’t have experience in automation.

As an automation engineer, I want to help close this gap between what the business needs and the skill set of our employees. I pitched an idea to our QA leadership to allow me to run a full day internal workshop on Selenium WebDriver. They loved the idea and gave their full support. They have even arranged for me to conduct the workshop at multiple sites within the company.

There’s quite a few Selenium workshops/tutorials available online, but when reviewing them, they seemed to all be very elementary. While that’s fine for introducing someone to a new technology, it doesn’t give a true sense of what an automation engineer actually does. For example, the classic example I see online is a login page with the example test illustrating how to set the user field, set the password field, click the submit button and then verify the title of the home page that you’re taken to. Good demonstration of a very basic use of the Selenium WebDriver API, but unrealistic of the types of applications and checks that I actually have to work with day to day. I read an article recently that has stuck with me: Stop Lying to Newbies, where Kim Crayton warns us not to mislead people into thinking that programming is easy, only to have them terribly discouraged when they finally learn the truth. I didn’t want this workshop to be that. I chose to show them the truth…what a day in the life of an automation engineer is truly like. So while Selenium is the tool that we use in the workshop, the bigger focus is the craft of automation in general.

I made a very simple application for automation that is easy to understand but still poses some of the common challenges automation engineers face on a daily basis. The app is a one page book shelf that shows a list of my favorite books on Automation and allows a user to filter this list by title, author, or price.

For the first workshop, there were 22 attendees. Most were testers with no automation experience, a few were current automation engineers looking to learn more, and a few were from other disciplines who just wanted to get a better understanding of what automation entails. The workshop had something for everyone!

We didn’t jump right into scripting. Instead, we took a step back and evaluated the application, discussed possible test scenarios, and then discussed which of these should be automated. There was lots of good information here about what makes a scenario a good candidate for automation. Once we all agreed on which ones should be automated, we prioritized them as a group to determine which should be automated first.

The technology stack we used included Java, Selenium Webdriver, Junit, and Chrome. After installation and setup, we created the structure for our automation framework with two initial packages: framework and tests. I took some time to go over how to build a framework that’s extendable and sustainable. I’ve seen a lot of Selenium tutorials where EVERYTHING is slapped into the tests themselves for the sake of simplistic demonstration. This is not a great practice, and definitely not something I wanted to teach aspiring automators. So, I made sure to talk quite a bit on framework architecture.

We developed a base test class whose purpose was to launch a browser, give us a handle to our application, and close the browser after each class. Our test class (and all future test classes) extended this class so that when writing tests, we never have to worry about launching the browser, etc. This will always be done by our parent class.

Next, we moved to the framework. We developed a class to represent our page using the Page Object Model. They learned how to inspect the DOM and find unique identifiers for the elements they needed. This was really a great exercise because while every element on the page had an id, that alone wasn’t always sufficient for the methods we needed. For example, this simple application uses ajax, like so many of the real life applications we have to automate against. So there were timing considerations that needed to be made, as well as handling objects that remain in the DOM but dynamically change. We needed to craft custom identifiers using xpath and utilize some of the other great Webdriver functionalities to come up with the logic needed for some of the things we wanted to do. I could see a bit of anxiety over the complexity of this exercise, but these are the exact types of problems I have to solve everyday as an automation engineer. I think it was important to show them this side. And hey, when they run into these types of common challenges on their own teams, they’ll have examples of how to code for them. I did explain that as a new automator, it’s not typical for them to be expected to do this on their own. These types of tasks are typically done by more senior automators or by a developer.

At this point we took a break for lunch. This was perfect timing, as we’d done most of the heavy lifting and I was sure they’d want to give their brains a rest. However, to my surprise, most of them grabbed their lunch and came right back to their computers to study the code we’d written. They used their lunch break time to digest what we’d gone over so far.

After lunch, I recapped what we’d done so far – explaining the code we’d written and reemphasizing the rationale behind it. Then, we moved on to coding the scenarios. This was much more straight forward given we’d laid the foundation with our page object class. However, there were still a few planned gotchas. While coding the page object class, I allowed them to tell me their logic and as I coded it, they coded along with me. There were some key things missing that I recognized as an experienced automation engineer, but that wasn’t obvious to them when giving me their logic to code. Instead of correcting them right then, I made private notes of things that I knew would come back to bite them when they went to execute their scripts. Sure enough, scenarios that had initially passed began to fail when they added additional scenarios. I explained to them what was happening and we made our page object class more robust so that it can handle these types of things.This was a great exercise to expose assumptions that are easily made and how they can lead to brittle tests with intermittent failures.

After coding a couple of scenarios together, I allowed them to script the rest on their own. I watched as people collaborated with their neighbors to bounce ideas off of them, or compare scripts to see why one was working and one wasn’t. I let them know when it was time for breaks, but they didn’t move. They were extremely engaged. It was fascinating. Did I mention these weren’t Java programmers?! Given what they’d learned so far, a couple of examples, and teamwork, they did just fine! 🙂

The attendees left with several scenarios automated, a greater understanding of what an automation engineer does, and a sense of accomplishment for building their very own framework.

The attendees anonymously rated the workshop a 4.95 out of 5 and overwhelmingly enjoyed the hands-on interactive aspect!

Interested in attending this workshop? Check my calendar of upcoming events!