Considerations for optimizing HIT system testing
Another upgrade coming down the pike? New integrations in the future? Time to replace some hardware? In the dynamic world or HealthCare IT something is always changing in your environment whether it is being driven by application updates, new interfaces or other add-ons, or core IT demands and you know all of them require testing. The question is what/where, how much, and by who. Too often the answer falls back to simply how it was done the last time or no real answer at all. Particularly in the HIT environment of today with IT and application team budgets being squeezed the staff available for testing is very often the same staff that is already building, supporting or rolling out your systems. As such, refining your testing strategy is key to maximizing their time and the quality of the testing being done. Here are some factors which should drive your testing strategy:
Document, Document, Document!
Regardless of the exact approach your organization has used in the past or choose to use in the future adequate documentation about your environments will prove invaluable. Knowing how the system is actually being used or how it is “supposed to behave” sounds obvious but actually requires substantial upfront and ongoing effort and discipline to document and keep documented. Knowing how a system is supposed to behave saves testing time as less time is spent researching if a behavior is a bug or working as designed. Knowing how users are actually interacting with the system helps target testing if time and resources are short and prevents wasted time by testing areas of the program that may not be used or not used in the manner tested.
Unit Testing vs. Workflow Testing
While endorsed by less and less vendors many organizations choose to perform full and detailed unit testing for every upgrade. This involves reviewing every screen and clicking every button to make sure everything “works”. While thorough, this method is extremely time and resource intensive and may actually prove to be a less accurate approach since it is often done based on general/best practice workflows or regardless of workflow entirely. Not testing the system as it as actually being used wastes time and potentially misses issues that your users will be sure to find first thing in the morning.
By having your workflows documented your environments can be tested in the same way that your users will be using the system. Putting a focus on workflow testing maximizes the testing staffs’ time and optimizes the quality of the testing. Testing end user workflows should be the first priority of any testing strategy but should be followed additional, targeted, unit testing based activities
Knowing What’s Changing & Know the Usual Suspects
After the primary focus of testing end user workflows the testing strategy should shift focus to targeted unit testing with the two main areas for attention being the aspects of the environment that are changing and the parts of the environment that have historically seen issues during similar changes. The former requires thorough review of release notes, known/resolved issue lists, and other supporting technical documents to get a full understanding of what aspects of your environment changing. The latter primarily requires experience with similar changes in the past but such knowledge can be augmented by participating on community forums or speaking with experienced consultants. Putting your effort into these areas will allow testers to get the benefits of the thoroughness of unit testing without the time consuming drawbacks of its “touch everything” approach.
Your testing strategy should be targeted and proportionate for the conditions changing in your environment. Obviously a major application upgrade warrants a more robust testing strategy and the time associated to it than adding some additional memory to a webserver. The primary focus should always be putting the system through its paces from an end users perspective and then expand from there as appropriate. Subsequent emphasis should be placed on what is changing and what has been known to break in the past. Paramount to everything is proper documentation of workflows, expected application behavior, environmental topography, previous upgrade experiences and the testing strategy itself. Upgrades are stressful times so getting your house in order with regard to proper documentation ahead of time can help avoid major headaches during an update. Doing so may require reallocating staff or even augmenting your staff with additional help but doing so will be well worth the investment.