Article

Testing for the unexpected: Is the unexpected really unexpected?

Executing every test in a test script for every feature in a 10-year-old ATM system is impractical. So how do you maintain the integrity of your configuration?

June 11, 2015

ATM Marketplace is pleased to present new blogger Mark Medlin, CTO and cofounder of Paragon Application Systems, a global provider of e-payment simulation and testing solutions. Mark will be blogging regularly about issues and innovations in ATM software development and testing.

by Mark Medlin, CTO, Paragon Application Systems

Any software integration project — whether it requires software development or the integration and testing of packaged components — involves a host of people on the team analyzing and testing for improbable scenarios. 

While they would never expect them to happen, they still test the edge cases and outliers to make sure that the integrated solution meets expected tolerances.

For example, a properly functioning ATM would never send a transaction with the same message coordination number as the previous message. This scenario is improbable, but is usually tested when an ATM device driver is initially developed.

However, once the integration effort is complete the team's thinking moves on to the next effort. Many of those edge cases and outliers are either forgotten or buried in volumes of test scripts that simply can't be executed at the speed required by today's rapidly changing electronic payment infrastructure.

When a failure occurs years after the original feature is deployed it's usually because updates or configuration changes broke the once-working feature. The behavior is unexpected for the new effort, but years ago, it was a scenario that was tested. Given enough testing resources it might have been avoided, but executing every test in a test script for every feature in a 10-year-old system is impractical.

One solution to the problem is to incorporate test-driven development and behavior-driven development into the delivery process.

Don't let the word "development" in the TDD and BDD acronyms fool you. These processes are just as applicable to people responsible for integrating packaged components in an organization as they are to development specialists.

With both of these processes, the team responsible for the health of the integrated system is required to codify all software behaviors in executable tests. These tests become part of the test suite, ensuring that any feature will continue to behave appropriately as long as it exists.

Ideally, the testing framework will be integrated into a continuous delivery process that will automatically execute each of the tests any time the software configuration changes.

A key part of this process is having a quality test suite for all your development efforts. Stay tuned for a series of blog posts about developing and describing a quality test suite.

photo istock

Included In This Story

---

Paragon Application Systems

Paragon ATM simulation tools provide the features, functions and flexible automation options so that you can run more tests in less time - improving quality, shortening delivery cycles, reducing costs, fostering collaboration, and increasing channel profitability.

Request Info

Learn More