What Does it Take to Become a Real E2E Test Automation Engineer? Part 1-A: Broad Knowledge

This is an abrdiged version of my Medium Article, 2023-12-12.

Real E2E Test Automation Engineers are rare, even at software giants (long-time readers have seen the quotes) such as Google, Microsoft and LinkedIn. Just give an idea of how rare it is, I came up with an analogy:

“Real E2E test automation engineers are like Michelin-star restaurants. Senior ones are Michelin 2-stars. When someone says there is a good restaurant next to his living place, the chances are it is not Michelin-1-star, and almost certainly not Michelin 2-stars.”

Not convinced? A simple question, do your E2E Test Automation enable your team do daily production releases? I do and have trained some accomplished that too. Check out this article, “Showcase a 500+ End-to-End (via UI) Test Suite: E2E Test Automation is Surely Feasible for Large/Complex Apps”.

As usual, let me start with a story. Many years ago, I joined a team as an automated tester (contractor). After seeing my work, the senior project manager (a former developer) quickly discovered the great benefits of E2E test automation. Filled with enthusiasm, he composed an email to the executive director. The first sentence was (he showed me), “I am writing something that you won’t believe, but it is true, I am seeing a revolution …”

He used the word ‘Revolution’ to describe E2E test automation & Continuous Testing. The same word that Wired used in this article, “The Software Revolution Behind LinkedIn’s Gushing Profits”.

Of course, the executive director ignored it. The senior PM took action to self-learn E2E Test Automation: bought my book and TestWise license. Nearly every day at work, he asked my testing questions during the lunch break, such as, “Zhimin, I did some tests last night and have a few questions. Can you have a look?”

One day, he casually asked, “Zhimin, what skills are required to be able to do E2E test automation, like you?”. I thought about it that night and wrote down a long list (in the article). The next morning, after seeing it, the PM said, “People who have all these skills are gold”. Interestingly, “Gold” is the same word used by Patrick Copeland, the head of engineering at Google, who managed thousands of top-level software engineers in the world, to describe real test automation engineers as well.

“In my experience, great developers do not always make great testers, but great testers (who also have strong design skills) can make great developers. It’s a mindset and a passion. … They are gold”. - Patrick Copeland, Google Senior Engineering Director, in an interview (2010)

In this article, I just focus on one aspect: the broad technical knowledge required for a real E2E Test Automation Engineer. Stay tuned for future articles on other aspects.

For easier reading, I split the long content into three articles. This is the first one; the other two will be available soon this week.

The Skills Required by a Real E2E Test Automation Engineer

Below is a list of skills I have used in numerous test automation projects. I list them in categories.

1. General Programming

Automated test scripts, in essence, use a programming language to perform automation tasks, i.e. coding with a different purpose from the developers. For ‘automated testers’ believe “Record-n-Playback”, “Scriptless Test Automation”, or “AI (ChaptGPT) Test Automation”, please stop reading this article. I wish them luck, as I haven’t yet seen one with the above approaches remotely close to being successful over the past 18 years.

While programming knowledge is mostly generic, there are specific ones:

• Object Orient Design
• Several common mainstream developing languages are Java, C#, and JavaScript.

A few years ago, a principal software engineer who led a team did a very bad and embarrassing E2E test automation (using Java and Concordion, a Gherkin syntax). When I was tasked to re-implement, this principal software engineer sabotaged, which is not surprising. My first task is to create five end-to-end typical test scenarios. I was given a bunch of complex and badly designed Java Test code, without any documentation, to convert from. When I told the Proof of Concept team that I accomplished that at the end of first day, with test scripts and execution videos, this astonished the team, especially the principal software engineer. He did not expect my Java knowledge to be so high, able to decode those five-layer badly designed Java code.

By the way, I implemented it in raw Selenium + RSpec, using TestWise IDE.

To be continued: Part B and Part C.