Just starting out with test automation? Don't make this mistake

Originally Published on TechBeacon, 11/11/2019

Paul Merrill

CEO, Consultant, Beaufort Fairmont

I often work with clients who are either just beginning, or trying to grow, their test automation capabilities, and more often than not they all make the same, fatal mistakes.

While they may understand test automation basics, they still see the value of scripted tests as saving time by executing scripts automatically, rather than by hand. They reason that, if automated scripts execute faster than humans can do it, then the largest gains in efficiency should come from automating the longest-running tests.

And if execution time were the only time to value, they'd be right.

But test execution time is just one time-related concern. You also need to think about the time it takes to write automated tests and the time you need to learn how to write the tests. 

Teams succeed more often when they whittle down big tests into smaller, shorter ones. Here's how you can benefit from this non-intuitive idea.

Leave time for learning

Toddlers learn to balance before they stand. They stand before they walk. Programmers write "Hello world" each time they learn a new programming language.

Teams learning to automate may move through several learning curves at once: a programming language, programming concepts, test automation tool or framework, source code management, and collaboration on a software project.

Each time you add a parallel learning objective, you increase time to proficiency. 

Recently, while planning a major transition to test automation at a large insurance company, I realized that just the concept of "conditionals" can take people days or weeks to absorb.

Thinking back to college, we spent one full week on conditionals. That's hard to believe now. The concept is so fundamental to me, it seems simple. But it's not to someone who has never been exposed to it. 

Remember that the time it takes to learn a concept is much easier to underestimate than you think.

Many times companies expect people to learn to code in a week and start producing good test automation immediately. That's insane. Why would I get a week to learn about "ifs" and "elses" in college, but a person with no background gets just one week to learn all the tools they need to do basic programming?

The lesson here: Keep tests short so that your staff is forced to learn fewer concepts. This will speed up learning—and productivity.

Gain momentum

This is the single most overlooked contributor to strong test automation efforts. A team either stands still or moves. If it moves forward, even a little, you're in a better situation for your journey.

Why not make the first move a little one? Why not start with a small test as the first one your people write? A small test as the first one for a new feature? A simple tiny GET request to a new endpoint in your API testing?

Waiting for the perfect tool choice, the perfect use case, the perfect set of resources is not progress. It's standing still. That lack of momentum—zero, standing still—encourages more of the same.

Perfect, too often, is the enemy of "good enough," which moves forward, gains motion, and increases momentum in a direction. A small test that is "almost right," even in a slightly wrong direction, can be modified and corrected.

Let your team experience progress, momentum, and small wins by writing small tests first.

Build mind share

When your people work on a longer-running test case, it is likely that these test cases consist of more complex scenarios. When people new to test automation spend their energy learning complex scenarios rather than creating test automation, their minds churn with limited mental energy. 

When you focus your thinking on the mechanics of test automation, you'll learn test automation more quickly. And when you do that for complex business logic, you'll learn complex business logic more quickly.

Teams learning test automation should focus first on learning test automation. Don't let complex business logic dominate your our thinking when you're working to learn automation skills. Leave those long, complex tests for those with greater skill.

We don't ask new musicians to play with others, perform on stage, and learn a new piece all at once. We don't ask first-graders to do algebra in their heads to figure out the change they'll get back on the lunch line they're standing in. So let's be as thoughtful toward those who are new to test automation: Have them write short tests.

Testers must learn multiple skills at once

The longer the test case, the more likely the person writing it will need more complicated features in the automation tool. 

When you learn, you must learn the foundational concepts first (grammar). Later, you build on and connect those to learn more high-level skills (logic and rhetoric).

The longer the test case, the more likely your new automators will need to learn more skills to complete it. This slows progress and demotivates people. It also delays the reward people feel when they get a test case finished.

And that feeling, or reward, is important. It's the reason many programmers continue to program, even when what they are working on is difficult.

So make tests shorter to reduce the skills the automator must learn. They have to learn a lot of skills, but they don't need to learn them all at once.

Automation is a software development activity

Test automation is a software development activity, and it's difficult to learn to program. Even with codeless tools, testers quickly find the limits of the tool and must learn more difficult concepts.

We make stories small in Scrum teams for many good reasons. The same reasons apply to tests you automate. Your automation should be tasks or stories in your sprints. You should make them small, just as you would other stories, so that you can gauge progress, iterate on them, and get feedback on them.

If you're not getting feedback on how your automation helps testers, developers, and product owners, you're developing software that's likely good for no one.

Starting small, reap the benefits

There are many benefits to writing smaller tests: You learn faster, contribute sooner, create forward momentum, and get more frequent feedback. It's also more fun. So start small, and build from there.

Has this tactic worked for your organization? Post your comments and let me know about your team and what you've done to make your tests smaller.