Tip 14 in the Interoperability Tip Series
In last week’s tip, we talked about capturing workflows.
Here’s why. Before you can conduct any interface testing, you must understand what to expect of your workflows. This should include common workflows – such as a patient being transferred – involving the use of the products that will be interfaced.
For example, in many hospitals, emergency department and in-patient ADTs are two separate systems. A new patient that comes through the emergency department would be registered in the ED’s ADT first. And if she is transferred to Med/Surg, you would need to populate the main ADT, either through an interface or manually by re-entering the data.
Or if you’re creating an interface to move patient charge data from a surgical information system to a billing system, you would need test scenarios in which:
- Patient demographics and patient ID are incomplete.
- Billing item information is incomplete.
Interfacing workflows: normal use cases and edge cases
And in fact, this is why is you need to test normal use cases as well as edge cases – where the data is incomplete, or otherwise deviates from the norm.
Interface testing: is the engine behaving?
With that understanding in place, you can test to make sure the interface engine behaves as expected for standard – as well as unexpected – workflows. When it comes to edge cases, you’ll need to consider more possibilities.
For example, if your interface engine does not accept a certain range or type of data, you’ll need to send such data to it – e.g., a date of birth of 1850 or entered in reverse – and see if the interface triggers an error.
Does the code have new errors when you correct a previous bug?
Are you introducing errors during testing? You’re testing the data format and confirming that you’re not introducing errors.
When you code an interface, your specification will be based at least in part on sample messages. By definition, you know that these messages work. So don’t use only these sample messages in your texts.
The danger of limited test messages in interface testing
Let’s say your test patient in your sample messages is called John Smith – with four characters in the first name. You test your interface using these sample messages, and everything works. But three months from now, your hospital admits a patient named Benjamin O’Donnell, only no one tested for 8 characters in the first name and an apostrophe in the last name. The interface doesn’t like it, and you have a support call (and a none-too-happy clinician) to handle.
This is where test automation comes in
By automating your testing, you will feel freer to test at any time and you’ll be more confident about making changes because you’ll know you can easily test each time you change the interface as you’re coding.
Learn more about test automation
Want to see how Caristix technology automates testing? Check out this 2-minute excerpt on interface testing and validation from our on-demand demo. See how to prevent costly project rework and delays.
Image credit: TheTurfBurner, Creative Commons licensed for reuse