Testing Plan: Enterprise Systems
Similar to the Data Migration Plan, in preparing the Project Document and the Detailed Project Plan, a few other planning documents are created including the Testing Plan. It makes good business sense to test a system before it is released to end users for production use regardless of the compliance requirements.
At the beginning of the project, before contracts are signed with implementation partners, the Project Manager in collaboration with the implementation partners and the functional leads should begin to draft the Testing Plan to make sure there is a clear understanding of what needs to be tested. This impacts the scope of the project, scope of work by implementation partners, internal resource requirements, and the overall timeline.
As the new system (or systems) is (are) understood by the internal project team, and as the implementation partners and project team gain a better understanding of the business processes, the Testing Plan is revised and expanded to include the additional details until it is finalized prior to execution.
Waiting to create the plan may (I would argue that it will) lead to project scope changes and delays, similar to delaying the development of the Data Migration Plan.
Who creates: Project Manager in collaboration with the functional leads and implementation partner.
Who approves: for controlled systems (SOX, GxP), approvals are generally required. For others, it depends on internal business process requirements and what was defined in the Project Document. Systems subject to SOX are approved by the functional leads and Business Sponsor. Validated systems (GxP) are approved by functional leads, the Business Sponsor, and QA in alignment with document control procedures.
When: an initial draft is generated as part of the project planning and revised throughout the project as more is learned and the testing specifics are fleshed out. If approvals are required, it is approved prior to execution.
What’s Included
Purpose: defines what is included in the document and why the document exists.
Scope: details what is and is not included in the testing activities. This includes the different testing such as unit testing, integration testing, validation testing (if applicable), and automated testing. Note: data migration testing should be included in the Data Migration Plan and not the Testing Plan.
How tests are to be designed and who is developing / approving (if applicable) the tests: defines how the tests are to be designed, what is being verified, who will be developing and approving the tests if approvals are required.
Who or how the tests will be executed: this section outlines who will be executing the tests, approximately when the tests will be executed, and how they are to be executed (end users or automating testing).
How testing will be documented and by whom: if it isn’t documented, it didn’t happen so this section defines how the testing will be documented and who is responsible for it. If testing approvals are required, they are outlined in this section.
Issue management: I’ve never had testing that didn’t result in issues. This section defines how the issues will be captured / documented and the resolution process.
Affected documents to be updated as a result of testing: with controlled systems, there are deliverables such as requirements documents, configuration documents, workflows, and work instructions. If changes to documents are required as a result of any testing issues and associated resolution, the list of documents that could be affected is included in this section.
Expectations after successful test execution: once testing is successfully completed, and reviewed if applicable, and a test summary is generated and approved (if applicable), this section defines what the next steps are.
Approval(s) (if applicable: I recommend that despite the controlled status of the system (SOX, GxP), that there always be an approver even if it’s just the Business System Owner. This section will have lines for the approver signature and date.
Other Things to Note
As noted above, if the system is being validated, the documentation and process requirements are more rigorous and are generally defined in corporate procedures for computer system validation (CSV) or computer software assurance (CSA). The testing plan may be considered an administrative planning tool or it could be considered a validation deliverable.
SOX controlled systems generally require an approved testing plan, documented testing, and a summary of test execution, including approvals.
How long is this document? Once again it depends on the complexity of the project and whether the system is a controlled (SOX, GxP) or not.
Why Share This Now? Back when I was an accountant, working for my dad’s accounting firm, we had a lot of small businesses as clients. The owners of the small businesses struggled with basic bookkeeping and accounting which meant that we couldn’t add value to them and their businesses because we were so focused on the fundamentals. We created a few accounting classes for them in the form of Accounting 101, 102, 201, and 202 so we could do more with them.
I’m applying the same principles here. If I can help my clients (prospective or current) help themselves with projects and project deliverables, then I get to elevate my role beyond the day-to-day and into a strategic and advisory role which, frankly, is a lot more fun!
Check out my blog post Project Deliverables: Enterprise Systems for the complete list of deliverables with links other blog posts.
Have Questions or Require Assistance?
Feel free to reach out to Terri with any questions you might have via email at terri.mead@solutions2projects.com or through the company website SolutionsProjects, LLC.
About the Author
Terri Hanson Mead, MBA, PMP, is a technology and compliance strategist for biotech, pharma, medical device, diagnostic, and digital health companies. Through her company, Solutions2Projects, she helps life sciences companies align technology roadmaps with corporate objectives and meet IT compliance requirements in a complex and regulated industry. As an expert witness, Terri provides pre-litigation consulting and expert witness services for failed technology projects, including enterprise systems.
