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 stillsee 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 humanscan do it, then the largest gains in efficiency should come from automating the longest-running tests.
And if execution time were the only time tovalue, 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.
Teamssucceed more often when theywhittle 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: aprogramming 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 youthink.
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 isforced to learn fewer concepts. This will speed up learning—andproductivity.
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 asmall 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 ofmomentum—zero, standing still—encourages more of the same.
Perfect, too often, is the enemy of "good enough,"which moves forward, gains motion, andincreases momentum in a direction. A small test that is "almost right," evenin a slightly wrong direction, can be modified and corrected.
Let your team experience progress, momentum, and small wins by writing small tests first.
Build mindshare
When your people work on a longer-running test case, it is likely that these test cases consist of more complex scenarios. When peoplenew to test automation spendtheir energy learning complex scenarios rather than creating test automation, their minds churnwithlimited 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 automationshould focus first on learning test automation. Don't let complex business logicdominate 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 thelunch 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 mustlearn multiple skills at once
The longer the test case, the more likelythe person writing it will need more complicated features in theautomation tool.
When you learn, you must learn the foundational concepts first (grammar). Later, you build on and connect thoseto 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 theydon'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 toprogram. 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 youwould other stories, so that you can gauge progress, iterate on them, and get feedback on them.
If you'renot 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: Youlearn 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.
Keep learning
Take a deep dive into the state of quality withTechBeacon'sGuide. Plus:DownloadthefreeWorld Quality Report 2022-23.
Put performance engineeringinto practicewith thesetop 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discoverbest practices for reducingsoftware defects with TechBeacon's Guide.
- Take your testing career to the next level.TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
