Test Design is Mostly Unnecessary in E2E UI Test Automation

Just mirror what an end-user does and focus on the common ones first. Make sure the existing tests are solid and up to date, before worrying about a test design that covers ‘all scenarios’.

Image credit: https://pixabay.com/photos/startup-whiteboard-room-indoors-3267505/

Here, I am referring to test design at test case levels, and doing that for over a few minutes after you know how to perform the steps manually. The overall test plan is still required, but shall be a minor activity though. For most web apps, the test plans are quite similar: you can use the same good automation framwork, e.g. Selenium in the largely same good scripting langauge, e.g. Ruby.
For example, the test plans I created for numerous client projects since 2011 included the same content, outlined in the AgileWay Test Automation Formula.
Also, Check out my “35-Word Functional Test Automation Strategy”.

A common mistake that junior E2E Automated Testers make is over-planning test scenarios. Below is an example.

it "Login Failed, User not exists" do

end

it "Login Failed, Passord lengh < 8" do

end

it "Password does not match the user" do

end

# dozens more ...

Some would argue, “This is called Test Design”. Yes, in theory, this is correct. Automated testers justify by saying, “This way, I won’t miss a scenario”. This view is wrong unless for extremely rare mission-critical apps. There is no “100% coverage” in Automated E2E Software Testing.

But in reality, it is the usefulness that matters. For example, I have seen a comprehensive test design (maybe 50+) for a payment test suite. However, the implementation/execution of test automation was poor, and regression errors, even for standard happy-path payment scenarios, often found in test and staging servers. What’s the use?! The project eventually ditched the test automation (the automation engineer mucked around for a few months, and his contract was not renewed because the project team members didn’t trust test automation and went back to 100% manual testing).

Let me ask four questions (from different perspectives):