Payments Testing - March 19, 2024
Like most organizations today, yours is facing increased pressure from both customers and competitors to innovate and change faster than you ever thought possible. Agile and DevOps – along with Continuous Testing – can provide the framework you need to keep pace with the marketplace.
Delivering software quickly, reliably, and safely is at the heart of technology transformation and organizational performance. We see continued evidence that software speed, stability, and availability contribute to organizational performance (including profitability, productivity, and customer satisfaction). Our highest performers are twice as likely to meet or exceed their organizational performance goals.
- Accelerate "State of DevOps"
In the first post of this series, Mark Medlin, Paragon’s chief technology officer and co-founder, and Eric Bergemann, Paragon’s director of product development began a discussion of the industry-wide drive from a traditional Waterfall development methodology to Agile and DevOps. Mark and Eric looked at some of the differences between how large and small organizations are affected by DevOps, as well as some of the ways to get started down the path.
In this post, we look more closely at why Continuous Testing is such a critical component of a successful DevOps implementation and explore some of the issues associated with legacy application environments.
Why do you think it's important for payment providers to implement continuous, comprehensive testing?
MM: The quicker you change; the faster more rapid deployment can come about. Companies need to get their software out the door and the testing cycle might be one of the places that causes delays. Automation is a big opportunity to fast-forward through some steps as an organization and move to more frequent deployments. If your testing is automated, you can use machine cycles for execution instead of more expensive human resources, so automation makes those tests virtually free.
You're not going to skip any of the testing steps if it's all automated, whereas with manual testing you might feel forced to skip tests as things go faster. With manual testing, the more you change, the more tests you must run. Organizations just can't add enough manpower to keep up with all this change.
As the entire payment industry continues to move faster, organizations that can test and deploy quality products and services more quickly will have a clear competitive advantage.
Firms running Agile+DevOps as a single transformation are 35 percentage points more likely to see improved technical quality and 28 percentage points more likely to see faster business value in the software they release.
- Forrester “The Definitive Software Quality Metrics For Agile+DevOps”
Is it problematic for organizations with a large installed base of legacy programs and applications? Is there a technology barrier or can you get around that with modern tools?
MM: Larger systems have always been tested through the interfaces that connect to them by building a test harness, and that can still be done automatically through software.
For example, instead of having a physical POS device connected to the system, you can connect something that acts like a POS device and perform those tests and verify the health of the system in that way.
The certification systems that we have in the field automatically perform these tests. There's no hardware involved. These are automated tests and a lot of the systems they flow through are old COBOL systems. And on the other side of the equation, there are so many new tools and resources available for people who are doing DevOps and continuous integration and continuous development.
People are the main ingredient in a successful DevOps initiative. When selecting members of the initial team, emphasize behavior over skills. Teaching technical skills is easier than teaching the correct behaviors — and the wrong behaviors will derail the DevOps effort. Look for a good team player who is smart, motivated, understands risk and is a committed lifelong learner, capable of working in new ways.
- Gartner
Is Paragon limited in any way by what our customers choose for their own environments today or are we able to support virtually anything in any of those new environments that a customer wants to deploy?
MM: Regarding testing, you always see continuous integration, continuous testing mentioned. When people talk CI and CD in the broad-based development community, they're thinking about test frameworks like NUnit or Junit or EasyMock–tools that test very low-level things. But, in a payment testing environment, it's critical that you have a complete integration test framework for continuous testing.
There are old systems out there that probably don't have these mocking frameworks, unit test frameworks, and modern things that developers are accustomed to, so we build our software with APIs. Every system today that is being built is going to have some form of API that one system uses to talk to other systems. One system can say, “I need you to provide this service for me.” And the other system responds and says, “I completed this.” We have an API that enables the system that is driving continuous integration and continuous delivery to reach out to our systems and say, “I need you to run this suite of payment tests and give me the results.” When we give the results back, those systems are able to carry on with their own processes.
The developers also need to run tests that go through the whole system and verify that their authorization transaction flow is correct. And that's where our app comes in. We can integrate with their continuous integration environment. They just need to set up API calls to our application and we can facilitate continuous integration testing with their build system.
EB: In this environment, if a test doesn't pass, everything stops. You fix the problem and then you keep going. Basically, the system does the job that the QA department formerly did. Now the QA department is auditing the automated tests and making sure the right tests are in place, working in conjunction with these modern systems.
One thing we have noticed over the past five or six years is that, in our clients’ organizations, the developers are taking a greater role in the testing of the software that they produce and they'll spend time during testing trying to get automated test harnesses around their applications and build unit tests or integration tests that can be run automatically. This allows the organization to run these large integration test scripts systematically, efficiently, and at a lower cost before they deploy their software.
Our clients typically have big QA departments that are burdened with continuously running the same manual tests for every new release of software. In the DevOps environment, it’s more of a collaborative effort between the testers and developers. The testers spend time thinking about how they can break the software, then the developers turn that into an automated test.
MM: At the end of any new release cycle, the testers are very involved. They’re finding issues as they’re working through the new feature. Developers are building test cases to protect against that flaw coming back into the system.
Working collaboratively, testers and developers have created an automated test suite. The great thing is the QA testers can spend more time developing and running manual tests that verify that new features are working properly, while the automated test suite conducts the repetitive testing.
It is impossible to automate all testing, so it is important to determine what test cases should be automated first. The benefit of automated testing is linked to how many times a given test can be repeated. Tests that are only performed a few times are better left for manual testing. Good test cases for automation are ones that are run frequently and require large amounts of data to perform the same action.
- Smartbear “Automated Testing Best Practices and Tips”
Of course, with big test groups, change does not happen overnight. The developers are working on releasing new software, and they can't just stop and codify these manual tests. It’s not like you can flip a switch on DevOps. You have to get started somewhere and you begin by thinking, “What are the failures that are going to bring the system to its knees? What are the tests that I need to make sure are done every single time?” Start there. You can't automate everything overnight. That would mean your developers are only writing automated test cases and they're not delivering new functionality.
Continuous integration and continuous testing are key aspects of DevOps, but there are also other use cases. For example, in certification test environments, we've integrated SAML which allows faster logins and integrates with existing environments to enable single sign-on.
How does Paragon’s own expertise with Agile and DevOps benefit our customers?
EB: Our developers and our testers have already made the Agile to DevOps journey. Many of our customers are just beginning that progression. We've got a wealth of experience-based knowledge so we can help guide them through the process. We recognize that the transition is going to be different for every organization, but we can share our experience and be a good sounding board.
—
In the third and final post in the series, we’ll discuss some of the ways that Paragon can help organizations accelerate their DevOps journeys and look at a few examples of how clients are using the technology to succeed in the marketplace.
If you’d like more information about how automation and API access can help integrate payments testing into your enterprise environment, contact us to learn more.
<< The Drive to Agile and DevOps: Why Continuous Testing is a Must [Part One]
The Drive to Agile and DevOps: Why Continuous Testing is a Must [Part Three] >>
Mark Medlin is one of the co-founders of Paragon Application Systems and currently serves in the role of Chief Technical Officer. Mark has been instrumental in the design and development of Paragon's entire product suite, the introduction and implementation of Agile software development, as well as the drive toward DevOps. Mark is a graduate of North Carolina State University.
Eric Bergemann is the Director of Product Development and a Master Engineer at Paragon. He has been with the company since 2003 and has been involved with the design, development and support of Paragon’s Next Gen testing solutions since their inception. Eric is a student of technologies and processes that facilitate efficiency and quality in all aspects of the software development lifecycle. He has a degree in Computer Science from Campbell University.