People say that “the only constant is change,” and it is certainly true. In development, programmers must always assume that any code they create will require subsequent modifications to accommodate changes to associated hardware or software.

The inevitability of change holds true as a test automation strategy, too. Developers need to assume that any automated tests they create will require updating. They need design their test cases with maintainability in mind so the programs can be used again and again, even as test parameters change over time.

I’d like to use this blog to highlight the need for maintainability and emphasize some of the key capabilities teams should have in place to make sure the automation tools they use can be maintained. In general, for best practices, a test automation solution must enable teams to modify capture and replay procedures; change the topology for new network elements; update responses for new versions; and adjust how quick calls are made.

Capture and Replay

Most people think of test automation as a “capture and replay” procedure, where you record parameters and values manually when creating a test case. Over time, however, the devices, software versions, response and command values and other parameters can change and updating the test case will be necessary. Prepare for these types of eventualities from the outset, when you design the test case. Just assume the test case will need updating and make sure you can get into the program to make changes later without writing an entirely new test case.

Topologies are always changing, and teams frequently need to modify the topologies used in their test cases to validate a service or functionality as routers, switches, or other components are added to the network or replaced. But it’s inefficient and unnecessary to change a topology for every test case affected by a network topology change. Having an automation tool that can modify the topology and apply the change to all relevant test cases will eliminate the need to manually adjust every test case with the same change. A good topology management tool can also help you identify the network resources needed when writing the test and deciding how to automate the tests cases.

Response mapping is essential for validating data speeds, latency, packet loss and other performance characteristics and should be supported by any automation tool. When running these types of tests, the team needs to be able to examine the values returned in the command-line interface, pop-up window or other field to see if the test was successful. If performance objectives change, the team needs capability to modify the response value in the test case accordingly and confirm that it works. Changing response values can be necessary at any time in a product’s life cycle—not just during the initial demonstration testing of new product or service—but at any time after the product is on the market.

Quick calls—reusable procedures that numerous people can include in their test programs without recreating the code—are often used in test cases. Quick calls can be automated in testing but teams need the ability to change the email address, response options or other value, depending on test objectives, without recreating the procedure or test case. Make sure the automation tools you adopt can offer this.

Maintainability is Achievable and Benefits the Test Organization

When evaluating test automation solutions or tools, consider whether the test cases you create can be modified as your requirements change. Ask if the tool will allow you to update topologies, response maps and quick calls for your test cases 6 months, 12 months or even years from now. By confirming these maintainability capabilities, you’ll future-proof key elements of your test program. This best practice will help maximize ability to reuse automated tests, make work easier for the test team, help shorten the test cycle, and help the business ensure the timely delivery of high-quality products.

For More Information

Well-intentioned, but inaccurate information of implementing a test automation solution has caused some organizations to forgo the benefits. Learn more about the reasons for the “Five Misconceptions of Automation” and how to dispel them.

If you’re interested in improving your testing processes and want to learn more about vendor agnostic approaches that can be used for lab automation, please visit our website. I welcome your comments and questions below.