TESTING, TESTING, 1...2...3
By Susan North
You’ve designed workflows, built master files, and created category lists. But the work is just
beginning! The key to a successful implementation lies with developing and executing a comprehensive testing
plan. Testing helps to identify problems with build, ensures the system is configured properly for the
workflows, and validates the desired results are achieved. Along with testing that the build is working
properly across the ambulatory applications, it is critical that the testing plan includes exhaustive
interface testing. The completion of a successful testing plan not only ensures the system is ready for go
live; it also serves to prepare the project team for system support.
The testing should be done in phases, and each phase has certain dependencies. Testing will most likely
start within each application. This is known as application workflow or unit testing. The testing scripts
should be derived from the documented workflows for each application. For example, the Cadence team will
test the workflows that involve registering and scheduling a patient, and the ambulatory team will test the
workflows that involve rooming a patient, documenting a chief complaint, entering vitals and simple orders,
etc. Be sure to include scenarios in the testing scripts to demonstrate what will happen if the workflow
isn’t followed. This is called “negative testing”. Identifying and resolving issues in this first phase will
set the stage for a more successful integrated test.
Interface testing will be done in phases as well, starting on a small scale to validate the interfaces
have proper connectivity and that messages are properly filing. This phase is considered unit testing or
communication testing. The interface team will play a large role in this phase, working with the application
teams to identify and correct issues.
The second phase will incorporate testing procedures on a much larger scale. Though it may not be
practical to test each procedure, it is beneficial to test as many procedures as possible. The more frequent
ordered procedures should be tested first. If time allows, each type of order should be tested. For example,
for lab orders, the testing should include several from each section of the lab: hematology, chemistry,
microbiology, anatomic pathology, send outs, etc. This will present the opportunity to identify build issues
and validate that the procedures are mapped. The results should be tested as well as orders. Enlist the help
of the staff from each ancillary department to enter results for the various orders. Much of the build needs
to be completed for this phase to be successfully executed. This includes completion of the EAP master file
for interfaced procedures as well as category lists that support EAP: specimen sources, order priorities, as
examples. From the experience obtained from several implementations, this is one phase of testing that
should not be shortchanged! Due to the sheer complexity of interfaces, this testing should be as robust as
possible.
Once unit testing is completed and issues are resolved, it’s time to move into full- blown integrated
testing. Here’s where it all comes together. All workflows need to be tested. The testing will encompass all
of the applications and functionality of all interfaces. Up until now, the testing has been rather silo-ed.
Now, the system will be tested as it will be deployed, as an integrated application. Validating the
reliability of patient flow across applications will occur. This will require a large team comprised of
AC’s, SME’s, perhaps trainers and super users. Be sure to include the ancillary staff that assisted in unit
testing, they will need to enter results for the orders. It’s very beneficial to assign a testing
coordinator who will keep everyone on track. The testing coordinator can also be responsible for documenting
and tracking issues. If due diligence was done during the unit testing, issues should be at a minimum.
Once the issues have been resolved and if time permits, do one more round of testing. This final check of
the system will validate that the system is ready for a successful deployment.
Here are a few general tips with regards to testing:
- Testing should be done using mock users who represent the varying roles established by the
organization. This will give an accurate assessment of how the user roles, profiles and security will
function during go live.
- When writing the testing scripts, be sure to adhere to the workflows! Use scenarios that accurately
represent the users, patients and providers.
- Include “negative” testing, to demonstrate and document outcomes when workflow is not followed.
- Remember to test all forms of printing, and be sure to include order transmittal routing in the
testing.
In conclusion, by executing a comprehensive testing plan and identifying and resolving issues, the result
will be a positive experience for the project team and end users at go live.
If you have any questions, comments or feedback, please feel free to contact me at
snorth@getvitalized.com.