Why Vendor-Specific Tools for Test Automation Come Up Short
Blog  //    //  Written By:
Five Reasons Why They May Be Helpful but are Rarely ‘The Answer’

 

ERP and EHR vendors are racing to release their own proprietary test automation tools (e.g., Infor TaaS). It’s no surprise given vendors like Epic and Cerner are rapidly expanding the scope and complexity of their platforms, while at the same time increasing the frequency and impacts of their upgrades and releases. Not many organizations can hope to keep up with this onslaught through manual testing alone.

However, we’ve seen over and over again that these vendor-specific tools may be helpful, but they are rarely the full enterprise answer for successful, value-driven test automation. Here are five common reasons why:

1. Fox Guarding the Hen House

Maybe most organizations are old fashioned, but our clients routinely express a clear preference for an objective, third-party test automation solution that isn’t inextricably linked to the source system(s). One of our clients calls this a “healthy audit-like mindset”. There’s a reason most software R&D shops separate software engineering from software QC/QA. There is a time-proven philosophy that those developing code shouldn’t be the same people testing it. This applies to healthcare test automation, too, within delivery settings.

We’re not saying any vendor intentionally biases their testing tools toward the success of their system. We are saying that the possibility undeniably exists — not in a covert tactic of letting bugs pass through but more so in the very design of the tools themselves. Those tools, by definition, are at risk of being “too familiar” with the source system. They “think” like the source system in their designs and capabilities. That familiarity poses the very real potential of sub-optimal test automation.
Test Automation Guide

2. Bare Bones Capabilities

Speaking of the designs and capabilities of vendor-specific tools, in our experience they can’t hold a candle to the far more robust and powerful capabilities of automated testing platforms developed by companies whose primary or sole business is testing, testing, testing…and more testing.

How could they? Testing companies live and breathe testing across a massive diversity of customers and often multiple industries. One hundred percent of their R&D investments go into better testing. EHR, ERP and other vendors who provide automated testing tools as an aside to their main bread-and-butter platform simply can’t compare in testing experience and commitment –and ultimately design and capabilities. Vendor-specific test automation tools aren’t bad. They just aren’t enough. [Santa Rosa uses a leading global third-party test automation platform as part of our Test Automation as a Service program.]

3. Misguided Testing Foundation

Let’s stay on the capabilities theme a bit longer. We believe Santa Rosa’s test automation program is unique in the healthcare market because it is 100% workflow-centric. Workflows are the foundation of everything that we do. That’s why our clients do not have to have great (or any, for that matter) manual scripts or well-documented workflows to launch our program. Some of the other tangible benefits of this foundation are that we never have to touch the source system software, and the program adds real value to training and system optimization.

Unfortunately, most vendor-specific automated testing tools that we’ve encountered were built on a foundation focused on software development, not workflows. The vendor takes the same tool that they themselves use internally to QA and test their own software and with some tweaks open it up to their customers for a price. This distinction is far more than mere semantics. It is the very DNA of the testing technology. Simply put: a testing tool built on a software development foundation is not the same as one built with a foundation firmly grounded in healthcare workflows.

4. Islands Unto Themselves

The profound challenges of achieving fluid cross-platform interoperability that impedes the value potential of source systems also extend to vendor-specific testing tools. Vendors will market their systems as easily interoperable with any other systems or data sources, but we all know the truth is something very, very different.

The same is true in our experience with vendors’ proprietary tools. They can provide test automation for other systems (outside of the vendor’s own portfolio) but the experience can be excruciatingly difficult to pull off. Case in point: we’ve found that developing end-to-end integrated scripts from the vendor’s system back and forth to various third-party systems can be a real nightmare to develop and even worse to maintain over time.

5. Technology is Not the Answer

Let’s suppose for a moment that none of the above considerations exist. Vendor-specific test automation tools (or any testing platforms, for that matter) are never “the answer” Technology alone rarely is. We can’t tell you how many times we’ve encountered organizations with testing tools mostly collecting dust on the proverbial shelf. They are purchased with good intentions. An initial set of automated scripts is developed. And within two update cycles, those scripts become outdated and no longer of value. Organizations simply lack the resources, and occasionally the expertise, to establish and sustain test automation momentum.

That’s why Santa Rosa’s Test Automation as a Service program is a full end-to-end solution that encompasses testing scope prioritization, developing custom scripts, and updating scripts over time for system upgrades and releases. To be successful, test automation must combine experience, expertise, capacity, and technology into a seamless, value-driven answer.

Vendor-specific tools may have their place in a successful test automation portfolio, but for the reasons cited above they alone are rarely “the answer”.

 

Test automation EHR

Related Articles