3 patterns for building a resilient test automation framework

Many companies find automation difficult. Developing a solid strategy while dealing with the fluid nature of teams is challenging.

However, there are ways to make automation that's more immune to changes in code, personnel moves, and skill sets while still being flexible and easy to maintain.

Here are three patterns to consider as you create your first, or your next, automation framework, so that you have a much higher chance of success. 

Gartner Magic Quadrant for Software Test Automation

Prepare the environment by preparing your team 

For test automation, preparation starts at the cultural level, with the people. 

Many people still feel threatened by automation. Although they may not tell you this, some are afraid it's going to take their jobs. But the truth is, automation is key to your company's survival and, therefore, so is adoption of automation.

Still, you need to manage the notion that even if a specific solution is the perfect fit for your company, it won't take effect if people don't feel as if they can, or should, use it.

Here are some tips to help with the cultural issues:

  • Carefully let people feel the pain of doing everything manually. Don't let them get so frazzled or stressed that they leave, but let them get uncomfortable enough that automation seems like a good idea.
  • Educate people that automation isn't meant to replace them, but to augment them. It's to free up time for them to focus their creative human energies on things that can't be automated—things that need raw human intellect.
  • Identify where that intellectual capital can be spent. It could be on forming better test strategies, thinking up different types of tests, or assessing where the risky parts of the system are.

When you get people talking about the mentally stimulating (and fun!) stuff, you'll be making them want to pursue that. Automation is what allows the time to do it. 

Everyone I have talked to about automation, including every client I've worked for, has said that automation efforts fail for one of these three reasons: 

  1. The solution wasn't very maintainable
  2. It wasn't very usable
  3. It wasn't very extendable

Because the next step is removing those obstacles, that means you have the freedom to pick any technology to start with.

There's no wrong answer. Don't be afraid to pick something and get started.

Pattern 1: Ensure maintainability

Once any code is written, it has to be maintained. And you may notice that some places need to be maintained more than others. In any case, you'll want to keep the maintenance time short.

Here are some tips:

  • Find where pieces of code repeat themselves. If you have to hunt down dozens (or even hundreds) of places to make a similar change, modify the architecture to prevent that.
  • Pay careful attention to places that are painful or time-consuming to update, even if it's already only in one place. What are better ways to consume data in that part of the code?
  • Take time to imagine you had 10x or 100x more tests. What would be hard to maintain then? Even if the problem is minor now, refactor those places when you are able to, so that you can scale later when you have to.

The more you adjust the design with maintenance in mind, the less time gets spent on it, which frees it up to add value elsewhere.

Pattern 2: Increase usability and reach

A common flaw in automation is that it's limited to a small number of users. Many frameworks require developer-level skills to operate. But the developers are often busy developing, and many testers don't have the knowledge to code at that level.

One solution is to increase the usability—the "reach"—of how many people can contribute to the automation effort. Here's how:

  • Consider using a behavior-driven development (BDD) tool, such as Cucumber. This lets you abstract code away and drive your automation with a layer of English, which everyone is familiar with.
  • Target a nontechnical audience. Although there are some technical testers out there, don't assume they are (or always will be) in your company. Limit the amount of code required to write test automation.
  • Solicit feedback on how your users find the automation to be. If it's clunky and hard to understand, find out what about it makes it that way, and then change it.

As you continue, ask yourself: What other ways can I enable other people in the company to write test automation? Or how can I make it so that minimal to no code is needed for creating new tests?

Pattern 3: Boosting extendability

Although it may seem nice to have a solid solution that's locked in and rigid, it's not wise. No tool will solve all of your challenges forever. This is why it's important to make sure your solution can be extended to include new features easily. Here's how:

  • Create "intelligent" code—code that knows about itself. So, for example, if you make a new class, can you start using it right away, or do you have to include that class everywhere first?
  • Make changes that are intuitive. Naming and directory structure are important here—both for use and for making it easier to know where to make extensions when the time comes.
  • Stick to a standard, even if it's an unwritten one. When people can see a pattern throughout a piece of code, it's much smoother to know exactly where and how to introduce new code later.

Is it going to be hard for others to add new libraries or code patterns? Do other people need to know about the nuts and bolts of the automation to use the changes? If the answers to those questions are "yes," work to make them "no."

The result

If you follow these three patterns—work on usability, ensure maintainability, and boost extendability—some interesting things happen:

  • Tests become trivial to write, because more people can do it easily.
  • The automation is much simpler to maintain, so time will be spent on more important things.
  • Features will be spliced in quickly, since there's a more open architecture.
  • And generally, the automation will feel and be more lightweight.

Every time you improve your automation, be sure not to damage its usability, extendability, or maintainability. Any obstacles to those three qualities should be removed as quickly as possible. The result will be an automation framework that organically grows to address the needs of your team, organization, and company.

Topics: Dev & Test

Popular Posts