How to Succeed in E2E Test Automation within a Team Already on a Wrong Path?

Refuse to be ordinary. Advice to Motivated QA Engineers on Making Impact.

Image credit: https://pixabay.com/illustrations/keywords-change-fish-individuality-2488210/.

This is an article requested by readers who are frustrated with their teams’ current wrong test automation framework, language or tools but fear to challenge.

In TIST 2010 and 2011 testing conferences. One attendant caught my attention. He sat in the same position in the front row for all my four speaking sessions. Then I asked him, “What do you think (my topics)?”.

He answered, “I really liked it and believe it is the right way to do E2E test automation.”

I continued with another question, “Will you try to apply those practices at your work?”

He shook his head with a shy smile, “I don’t have the confidence”.

I kept thinking over this conversation on the flight back. True, an existing test automation approach (Most were wrong. Otherwise, it would have worked because E2E testing for web apps has been unchanged for nearly two decades) means endorsed by the senior management or architect; how dare an individual test engineer challenge that?

Long-time readers know I have worked as a test automation engineer on various projects for a number of years. In other words, I experienced this situation a lot, almost at every client project. This article shared my approach and experience on this matter.

Table of Contents:
· Real End-to-End Test Automation is Extremely Rare
· You Can’t Win Arguments with Engineers/Managers who Have Never Experienced Real E2E Test Automation.
∘ 1. “We should use the coding language for E2E test scripts!”
∘ 2. “Ruby (or X) is a very slow language compared to Java”.
∘ 3. “Our company adopts BDD, so you must write E2E test scripts using Given-When-Then syntax”.
∘ 4. “You must get E2E tests running in our Jenkins or Bamboo CI Server”.
· Strategy: Human Factors
∘ 1. You can only prove others wrong with results, solid results, gradually
∘ 2. Acknowledge when you’re unable to perform their suggested tasks and pass the ball back.
· Strategy: Technical
∘ 1. Don’t point out the wrongness of the current test automation framework or approach. Play along, but do the correct implementation on side tasks as Plan B.
∘ 2. Select a proven formula. Especially the framework is well accepted.
∘ 3. Become really good at hands-on E2E Test Automation, by practice.
∘ 4. Find a Mentor, Optional but strongly recommended.
∘ 5. Don’t OverPromise, Slow and Steady wins the game.

Real End-to-End Test Automation is Extremely Rare

First of all, we should understand the game. Long-time readers of my articles have seen a number of quotes (from software giants and world-renowned authorities) on how hard it is to implement real E2E Test Automation as regression testing. Check out the quotes in this Boosted article, “A Tale of a Deceptive End-to-End Test Automation Engineer”.

Also, my articles:

• Definition of End-to-End Test Automation Success

• Showcase a 500+ End-to-End (via UI) Test Suite: E2E Test Automation is Surely Feasible for Large/Complex Apps

• “Daily Production Releases” Clarified

You Can’t Win Arguments with Engineers/Managers who Have Never Experienced Real E2E Test Automation.

Proposing a new test automation approach (i.e., correcting others’ wrongness) is usually in vain, and it most likely leads to meaningless and relationship-hurting debates.