By migration project I mean at this context a project in which the integration platform is either replaced or migrated to another. A project where all existing integrations are moved from the old system to the new one. These integrations might be few decades old. Often also some kind of upgrade is performed to this integrations (protocols, message formats etc.).
The programmer who implemented the integrations may have changed the emplyer or the documentation is on “usual” level. This is of cource the worst case scenario which seldom happens at full scale (luckily), but is still possible. What can and should be done in a situation like this?
Testing at the above situation is almost purely integration testing. No resources should be wasted on unit testing unless some technical components of the platform is tested simultaneously. Evaluating the test results is pretty straightforward; either the new output matches the old output or not.
Unfortunately reality is not just as simple as theory because almost all transactions cointain data that changes over time. Message counters, dates and times are examples of this kind of data. When these variables are taken into account evaluating if the test succeeded or not is not so obvious anymore. We also have to consider the message volumes. Because the special cases in the message flows are usually also the most vulnerable, these must be considered in test plans. In many cases only way to give these cases enough attention is to increase the amount of messages to be tested.
manual testing is in many cases both hard work and very time consuming
Derived from the previous notes, the manual testing is in many cases both hard work and very time consuming. Building an automated test engine has proven to be the right way in almost all migration projects AgentIT has taken part of. As the test engine is needed only once it’s often evaluated to be too expensive solution for the project to implement.
AgenIT is specialized into migration projects and has implemented massive amount of platform specific tools for testing. The tools are immediately in projects toolbox and the time needed for testing can be reduced greatly. Addition to the platform dependent tools we have implemented the cloud based test tool Truugo. It can be used to validate both message structure and content at once.
When Truugo testing profile is implemented before project, following pros can be identified:
- Testing profile can be used by help desk. This helps in solving message errors even before migration project.
- During migration project the Truugo SOAP and FTP interfaces can be used to validate large amount of messages.
- During migration project the tool gives precise and updated reports of tested amounts and errors.
- After project the profile supports the new implementations. Interface testing can be outsourced to the connecting partner.
AgentIT is a rock hard specialist in migration projects. In our coordination you’ll achive immediate savings while changing or updating your integration platform.