Legacy systems will always be a complicated matter. Data from various times in the past, created on systems from various pasts, using regression tests from various pasts, will need to be tested in the present on systems that are running in the present. From early on, it was known that automation testing would be necessary, due to the volume of test cases and limitations of time. However, this created a new hurdle (or perhaps I should say an old hurdle): legacy automation testing. Let’s take a look at how both medical data and automation evolved, before we address what happens next.
First, a little history lesson.
With the advent of computers, it became obvious that data could be tracked a lot easier electronically, which requires a standardization of fields. We needed to do this with a method of accounting that could track various kinds of transactions. Back in 1979, the U.S. started a general industry coding standard for EDI (Electronic Data Interchange) known as ANSI ASC X12. In 1986, the rest of the world adopted UN/EDIFACT (not as an insult to the U.S., probably). X12 continued to evolve in the U.S., which included taking on a HIPAA flavor in 1996.
This is all a generalization of what happened – in terms of countries and a growing list of X12 variations that I have not tried to list here. Now on the data side, records could be any of the many X12 versions (including HIPAA), or old-fashioned straight ASCII, or NSF (a medical coding standard since 1991, when it was adopted by Medicare). Your medical EDI-based system may have received transactions from various third parties, filling your system with a hodgepodge of coding formats.
Like X12, automation testing has had growing pains where growth adds new features, and compatibility has become a concern. Tests built on legacy automation systems can also pose questions for future use.
But the big question is, is it better to stick with what you’ve got, or is it time to innovate and shift to the tools of today, which are more capable and flexible?
The decision is yours to make, but there’s a lot of room for improvement if you go with a newer system.
Not all legacy automation tools are the same, so let us begin by listing some of the potential drawbacks. The tools may require developer knowledge of an old programming language (which limits you to those personnel with those programming skills, even for easy-to-understand changes). Your developer may need to be on hand during execution, in case an error happens that requires a coding change, or a fix to the configuration file. The older tool may, and very probably does, lack the ability to loop and inject varied data on each iteration (note: this is called data abstraction). The commands may be no more than recorded macros that are played back, without having the ability to be easily edited. The programming language may not be object-oriented, so the relocation of an element on the screen blocks execution. The older language may also lack flexibility that you may need for your tests. Each test case may need to be individually created through slow programming, instead of easily scripted through an easily repeated modular template. A small collection of scripts may need to be manually launched and synchronized by a specific order and timing (“generate the report using the system, then once it has fully generated, launch a scripted SQL query …”). The ability to coordinate reports results, or to confirm expected output, may be a manual process. It may be hard to alter a script to accommodate a system change (relocation of elements on the form, increase of a maximum field size, addition of a new required field on the form, etc.).
And the list goes on and on.
The important thing to realize is that the whole purpose of automation is to save time, improve coverage, and remove the potential for human error in the quality of executing your tests. And automation allows you to re-run without any additional man-hour component. The decision of whether you continue to live with your legacy automation tool, or upgrade to get the full benefits of current automation testing, is yours alone. But it is important that you realize what you are missing out on if you do not “get with the times” with a more current solution.
Author Bio:
Scott Andery is an expert marketer, author and consultant who specialize in software testing tools and resources.
Aptly named, Enclothed Cognition is the official Medelita blog for medical professionals interested in topics relevant to a discerning and inquisitive audience. Medelita was founded by a licensed clinician who felt strongly about the connection between focus, poise and appearance.
