Micro Focus is now part of OpenText. Learn more >

You are here

You are here

How to make the transition from test automation engineer to craftsman

public://pictures/greg_paskal_2017_1280x1280.jpg
Greg Paskal Director of Quality Assurance – Automation, The Dave Ramsey Show
 

If you're like most automation engineers, the time comes when you start considering whether to stay in the field or transition into application development. You're likely working with developers, building interesting mobile and web applications, and you start contrasting that with the everyday reality of automation development, which may be losing the excitement it once held.

Forget about app-dev envy. Here's how to transition from the mindset of mundane automation engineer to the ranks of a test-automation craftsman. Once you push beyond the basics of entry-level test automation, you can discover new opportunities that will lead you to an interesting career development in test automation.

Look beyond a single tool

Most automation engineers are loyal to the tool they first learned. But one of the first ways to grow as an automation engineer is to understand that other tools and technologies exist that enable awesome test-automation development.

Come to a place where you're open to other tools, regardless of them being commercial or open source. Recognize the tools' strengths and weaknesses, including the ones you're loyal to. This allows you to see what's possible across the test-automation landscape and can lead you to solve challenges you couldn't overcome with your current tool set.

To automate—or not

I hear QA managers and development engineers talk about automating the entire regression suite and every test case. This is simply bad practice and will ensure that you're automating the wrong things, with no ROI in most cases.

My good friend Joe Colantonio, host of Test Talks and the Automation Guild, often shares with his audience the importance of knowing what makes for a good automation candidate. Here's an effective approach I've used to identify the right tests to automate: 

  1. Prioritize manual test cases as critical, high, medium, and low. Check out the Minimal Essential Testing Strategy (METS) to learn about this type of test prioritization. Begin by reviewing your critical test cases as candidates for automation. Be realistic; some tests may not be easily and reliably automated and should be left to manual execution. Focus on automating the correct critical test cases first.
  2. Perform a basic automation evaluation of the test cases and the objects and screens with which they need to interact. This evaluation helps you identify problem areas with automating the test case and should reveal if the test case can be reliably automated or not.
  3. Set the expectation that once you build test automation, it will need to be maintained going forward. It's remarkable how often this point is forgotten, so that a bunch of tests get automated only to be left to get stale, useless a few months down the road. Once you build it, you will have to begin maintaining it going forward.

The art of object recognition and locators

The automation engineer who can craft great object locators is invaluable in engineering reliable test automation. This is certainly an area where I have found that my exposure to multiple tools and technologies has given me a big advantage.

When it comes to locators, I always consider the most stable and dynamic aspects of the application. For instance, functionality is usually more stable than the look and feel of an application. For this reason, I rarely build my locators to leverage any attribute related to look and feel, including class and CSS attributes. Instead, look for IDs and names of attributes that would likely stay the same, regardless of whether the look and feel completely change.

Be aware that there are many philosophies, teachings, and good and bad practices related to building locators. My best advice is to build your locators so they rarely need updating over the course of a few years. Some locator strategies—such as the usage of XPath—are poorly taught and can lead automation engineers away from the possibilities of an exceptional locator strategy. Great locators typically comprise two or three attributes.

If you are working with web applications, you should have a good understanding of HTML, CSS, Forms, and JavaScript. If you're working with mobile automation, get some exposure to app design, layouts, and objects.

In other words, take the time to explore the basics of developing in the technology you are writing test automation for. This will give you a major advantage over those lacking these skills.

Automation color blindness: Seeing beyond red and green

When you first got into the world of test automation, you were likely excited to see your test execute and hopefully pass (or maybe fail). This "red-or-green" view of the testing world is not all there is, however, for the software tester. There are things your test automation is telling you other than simply pass-or-fail results.

At my company, the product's manual test engineer owns all related test-automation projects. Manual test engineers own the execution and analysis of the test automation, which they run multiple times every day, regardless of whether it's a new build or release.

Why run your test automation so often? Because when manual test engineers start to see test automation as a tool in their testing tool belts, they begin to use it as a way to understand the operation and "personality" of the application they're testing.

Running your test automation on such a regular basis helps bring awareness of when an app is running as expected and when it starts running differently than expected.

I refer to this as a "gray" result. It's not simply telling you if the test case passed or failed but that it's starting to run differently than it did in previous runs. We find more defects before they become true fails by using this approach than we did by simply relying on red-or-green, pass-or-fail results.

Empower your manual testing team with reliable test automation. Enable them to interpret differences in test runs. Pay attention to test metrics such as test execution durations from one run to the next. Be ready to dive into the gray results that are telling you that something has unexpectedly changed.

It's important to remember that we are first and foremost quality-assurance engineers who develop test automation. Ensure that maintaining quality and reducing risk are the goals of your automated testing. A common trap for test automation developers (including me) is to fall into "the pursuit of green." This is a type of blindness, where we pursue passing (green) test cases at any cost.

Build for maintainability

If there’s one thing I've learned about successful test-automation endeavors, it's the importance of building for maintainability. This means including sufficient internal documentation and using naming conventions to make it as easy as possible to keep those tests running.

But maintainability holds a trap for test-automation engineers. They pursue test-automation development in the same manner as application development. They chase "DRY" (Don’t Repeat Yourself) coding principals that are appropriate for application development but not for test development. 

They forget that their automation code may require updating at any given moment. It should be as easy for your most junior test-automation engineer to maintain your test automation as it is for your most senior. Most fixes should be able to be made in minutes and be back up running in no time.

To help with maintainability, I've made a habit of implementing naming conventions across my entire test-automation framework and code assets. I like to use conventions such as LO_ preceding all my locator constants, PO_ preceding all my page objects, etc.

I suggest similar naming conventions for modules, libraries, reporting, and so on. 

Transition from journeyman to craftsman

Let today be a new beginning, as you transition from test-automation journeyman to test-automation craftsman. It all begins with seeing new possibilities and taking those next steps.

Start by applying the items I’ve discussed above, and lay out a plan to pursue these areas with passion. Consider where your skill set is now and what it would look like to master these areas with excellence.

Drop me a note sometime and tell me about your automation journey and what you've learned along the way. Encourage other automation engineers in your organization and community to continue moving the field of test automation into an art of craftsmanship.

Let your journey begin!

Keep learning

Read more articles about: App Dev & TestingTesting