Hi! I am Geert, product manager for the testing products at Anubex. I’m going to tell you a bit about automated testing, specifically in the context of migration projects.
Here at Anubex we perform automatic application modernization. That is: we migrate an entire application, typically from mainframe to Linux or Windows. At the same time, we modernize the underlying architecture: we bring old VSAM files to a relational database, we convert programs from COBOL, NATURAL or IDMS to Java or C#... Basically, just about EVERYTHING changes.
Needless to say that testing is an essential part of such a project.
And just like we have tools to automate the migration itself –the data conversion, the source code transformation – we also have tools to automate the testing.
So how does that work, automated testing?
Well, I just said that in a migration project just about everything changes: the programming language, the database, the operating system, … There’s one big exception, and that’s the BEHAVIOR of the application. The behavior is supposed to remain completely, utterly, 100% identical to the original one. The behavior of the application can be, for instance the screen output of an online application. Or the listings that are produced by batch jobs. In general, given the same INPUT, the migrated application should produce the same OUTPUT as the original application.
This is what we call “like for like” migrations: very complex projects, but in the end, straight forward to define “success”. Success is when functional equivalence is achieved; when the migrated application behavior is 100% the same as the original.
And that’s where our automatic testing tools come into play. They are used to prove or disprove this functional equivalence.
In a nutshell: we record the behavior of the original application: input and corresponding output, for each online screen, for each batch job. Then we replay the recorded inputs onto the migrated application. Same input should yield the same output. If we detect the slightest difference between original response and replayed response, we haven’t achieved functional equivalence yet.
Recording of the original application is rather straight-forward. People simply use the original application – typically on a reference environment. The test tool will capture network-interactions and will automatically convert that into a test scenario. That same test scenario can be replayed onto the target environment.
And the good news is, while the recording needs to happen just once, we can replay that recording automatically, 10 times, 100 times, 1000 times. Without requiring human testers.
So now we have automatic conversion tools, and automatic testing tools. Our migration project now becomes this iterative process in which we will run the conversion tools, then run the testing tools to find issues. We will fix some of these issues, then rerun the conversion tools, rerun the testing tools and see where we got. Because all this is done by software, execution is super-fast, and turnaround times are very short. We could reconvert AND retest entire applications in a matter of hours. And since we
retest EVERYTHING with each cycle, we can rest assured that we don’t introduce regressions, you know: fix one thing here, break something else there. At least IF this happens, we will find out immediately.
So yes this is a quite powerful setup. With each new iteration we can measure progress, black on white. And everyone can see the project evolve towards that ultimate goal: a migrated application that behaves exactly like the original one.
For me, automated testing is a key success factor in any migration project.
If you have any questions or remarks, feel free to leave a comment below, or visit anubex.com for more resources.
Thanks for watching!
