Healthcare organizations know how much clinical and non-clinical staff alike depend on the information technology (IT) they use to help in delivering and supporting the care they provide to the patients they serve.
However, many organizations do not understand the connection between having an organizational testing management plan and ensuring that IT being used works as expected and does not introduce issues as modifications are implemented.
This article will define what a testing management plan is, and why every healthcare organization should have one to ensure IT continues to work as expected as changes are introduced.
What is a Testing Management Plan?
A testing management plan is a document describing how testing will be managed for IT changes being implemented prior to being approved to go live by the Change Control Board or Project Management Office.
The objectives of the testing management plan are to ensure consistency and efficiency in testing practices for all IT changes and reduce the number of bugs introduced into production environments.
In the case of a Project, the testing will be governed by a Project-specific Test Plan, created by the Project Manager, incorporating any vendor-specific requirements, and based on the Testing Management Plan.
In the case of Production Support, the testing will be governed by the Testing Management Plan.
The testing management plan consists of the following six components:
1. Definitions of Testing Types and Terms
The definitions section of the Testing Management Plan defines the different types of testing:
- unit testing
- system testing
- regression testing
- volume testing
- integration testing
- user acceptance testing
- other terms that impact testing
It is often the most controversial part of the plan at the time of creation. It is often difficult to get healthcare organizations to agree on what is supposed to be accomplished in each type of testing, in which order the types of testing should be conducted, and who should participate in each.
Healthcare is different from most industries in that there are almost no organizations utilizing in-house developed software anymore. Commercially available off-the-shelf (COTS) software testing is different from testing in-house developed software.
This is one of the main contributing factors to the debate over definitions. With COTS software the focus is more on testing the configuration options selected and items that have been built into the system than testing the actual software functionality that has presumably received significant testing by the software vendor.
2. Testing Team Organization
The Testing Team Organization section of the Testing Management Plan identifies the types of resources and organizational bodies that will be required for testing and the roles and responsibilities of each resource type and organizational body.
Resources to be included will depend on the type of testing to be performed. They may be internal, vendor or third-party consultants. Examples include:
- application analysts
- business analysts
- interface analysts
- desktop support
- biomed
- project management
- subject matter experts (both clinical and non-clinical)
- informaticists
Organizational bodies would include the Change Approval Board and could include any other body within the governance structure.
The goal is to engage the correct resources who can critically evaluate the system modifications, understand the objectives of the process being tested, and to provide confirmation that the objectives will be achieved within the system as configured. The testing resources must have both understanding of clinical processes as well as perspective on the workflow within the system.
Note that the roles may vary depending on whether it is routine production support change, minor or major project.
3. Testing Management Processes
The testing management processes vary slightly too, based on what type of testing it is and whether it is a routine production support change, a minor or major project.
The basic processes are:
- confirming the testing requirements
- scheduling testing
- preparing for testing
- confirming readiness for testing
- conducting testing
- documentation of issues
- conducting issue resolution
The testing management plan outlines the details of each of these processes as well as which resources are responsible for each process.
4. Tools, Procedures, and Standards
There are several different types of tools that are required for testing. Some organizations use the same tools for each type of testing while others use a different tool for each type of testing or use rudimentary or few tools at all.
The types of tools that are identified in the Testing Management Plan are:
- a tool to schedule testing
- a tool to create and maintain test scripts
- a tool to conduct and manage each test round
- a tool to log and manage issues associated with each test round
- a tool to communicate the status of each test round
Scheduling includes more that just testers and rooms, it also includes the domain, hardware and devices that will be used.
Scheduling of testers is becoming much more important as healthcare organization try to cut costs. More and more organizations are looking to have better data available to only schedule testers on the days that they are required and be able to release them as soon as they are done for the day.
Being able to create and maintain test scripts has always been a huge burden to analysts. Organizations also need to know where each round of testing is at as it progresses, whether it is on track, how many issues are logged and the status of those issues.
They need to be able to communicate that information across multiple vendors. Having a tool that does all these things, for multiple testing types, is a huge win for any organization. It is also important that the tool is flexible enough to incorporate not only your standards, but also standards across your vendors.
Typically, healthcare organizations spend more on integration testing than any other types of testing. Looking at a tool that can reduce the costs for integration testing will therefore deliver the largest return on investment within this process for any healthcare organization.
5. Test Plan Template
Testing for production support testing, a formal test plan is not required. Testing for production support is governed by the main Testing Management plan.
However, for any project work, it is recommended that a test plan be created. The Testing Management plan usually includes a template to guide the creation of these project test plans.
Many vendors supply a test plan template for major IT implementations. This should be considered a starting point, rather than the final test plan.
The organization should develop their own test plan template so that testing resources become familiar with the plan and the steps outlined in the plan. Consistency and quality in testing become easier when resources use the same processes each time.
Specific vendor requirements are usually easily incorporated into the organizational test plan template. On the other hand, if an organization does not have a Testing Management Plan with the accompanying test plan template, the vendor test plan template should provide the framework for the organization to build upon.
6. Reviews
As with any good organizational plan, the Testing Management Plan should be reviewed at least annually to ensure that it is current and delivering the consistency and quality in testing that healthcare organizations need. If new tools are introduced into testing processes the Testing Management Plan should be reviewed at that time as well.
The Testing Management Plan, and associated documents, support the organization over time and should evolve with the IT processes, upgrades, and expansions.
Why Organizations Need a Testing Management Plan
A Testing Management Plan allows you to hold your team accountable because it defines your organization’s expectations with regards to testing.
Building consistency into your testing by having defined tools, procedures and standards adds quality to your testing. This makes your testing become repeatable and helps to ensure that your outcomes will be consistent too, ensuring fewer errors are introduced into your production environment.
Talk to Our Experts
You don't have to try to figure this out on your own. Get the help you need to ensure better outcomes and be confident in your testing approach.