With the increased popularity of APIs as the go-to means to integrate multiple applications, exchange data, and perform shared calculations and functions, organizations can't afford to ignore interoperability testing.
Interoperability testing verifies that components within the application, server and database work together and deliver the expected results. It's not sufficient to only test components or applications; you must test all the components with which they interact.
A development team could create mock systems that simulate interoperability testing for a solid first step. But simulations don't replace interoperability tests, which cover as many possible connection points and functions as possible for all partners.
Interoperability testing is challenging, which is why software development teams attempt to get around it. For example, in a partnership, one development team from Company A won't have its code ready until right before the expected release date, while Company B wants to thoroughly test their interoperable code before release. So, Company B's developers create mock code that simulates the existence of Company A's expected code. That simulation, while imperfect, helps both teams avoid logistical challenges.
Despite the difficulties, interoperability testing is the only sure way to confirm that components function and communicate as expected, if security practices are up to snuff, and if messages get through and go to the correct place.
Barriers to efficient interoperability testing are surmountable, with effort from the development team.
Security is often the first failure point in interoperability test execution. Get all parties on the same page to facilitate a secure handshake for every connection, response, message and data byte transferred or shared.
By design, the system components must communicate with each other securely. Work with all partners or vendors to establish a standard security exchange protocol, such as HTTPS, Lightweight Directory Access Protocol or Security Assertion Markup Language; otherwise, systems cannot communicate. The aforementioned handshakes must always occur. Verify that all providers use the same security best practices and re-create this setup in your testing environment.
More than any other form of communication, systems most commonly exchange data. Data must end up in the correct location, and it must be 100% complete. Data loss is unacceptable.
To perform interoperability testing, make sure you can exchange realistic data types during testing. You can mock or simulate the data -- such as healthcare lab results -- but the data type, such as a PDF, must be real. Otherwise, you will experience data compatibility issues and application functionality failures in live operations.
Multiple network components, such as partner vendors, data exchanges or connection endpoints, complicate the system. These systems are like a house of cards, in which every card relies on another to support the structure; one wrong move, and the entire system goes down.
Set up all the possible connections you can, and test against them as soon as possible. You might not duplicate 100% of the system complexity of the production deployment, but get as close as is feasible. The more you test upfront, the better you can address variations in system performance with real clients and customers.
When working with partner vendors, it's a big challenge to time the development effort so every organization's contribution is done and ready for testing on the same schedule. So, plan what you do if a partner gets behind schedule. For one, you can set up a QA environment with all the pieces in place, mocked or simulated. Then, you can fill in the missing pieces as development winds down and unit tests have been executed on the integrated code.
If you use an integration system that provides the back end and connectivity, and you customize code for what you need beyond the tool's native features, you can save resources and simulate testing when partners' code is integrated into the branch and passes integrated unit tests. Companies like InterSystems, IBM and Oracle provide the pieces to create an interoperable system, and you put them together as it works for your application, network and database.
If interoperability testing sounds a lot like system or integration testing, you're right. While similar, interoperability tests evaluate your application with other involved vendors and their separate applications. In other words, you test between software development companies that participate in a shared venture. For example, many healthcare applications interoperate with each other as a means to share patient and physician data across various computer systems.
An organization can find many ways to skimp on its testing budget, but you simply cannot skip building a completely interoperable testing system. It doesn't necessarily need to be state-of-the-art, but the system must represent the majority of your anticipated user base, which includes partner organizations, their endpoints, shared databases and application end users.
Decide how you will perform the test. You and your partners can meet up and hold an interoperability test marathon. Alternatively, you each can work separately with each other's test cases -- or even stick with your own test cases and improvise the rest.
Interoperability testing marathons, also called testathons, provide quick access to each partner's developer and QA resources. These events are a popular way to get IT staffs to work together and test, fix and retest until each partner gets positive results. Organizations can hold testathons in a shared physical space or within an online group chat, or a mix of both. With few partners, a shared phone call might suffice. But, generally, it's faster and more effective to test together.
13 Mar 2019