Whether you’re buying a new CMMS or upgrading an existing one, testing is one of the most important measures you can take to ensure a successful purchase, configuration, and implementation. This is especially true in today’s world of complex technology.
CMMS packages provide great flexibility and functionality while simultaneously raising the probability and impact of things going terribly wrong thanks to our rising dependency on technology. This is especially true when integrating various software, hardware, and telecommunications solutions involving multiple vendors, platforms, and versions. Testing helps identify problems and risks long before you undertake the costly and time-consuming process of moving a given CMMS application into the production environment.
Testing will answer two key questions: 1) Does this CMMS package meet user requirements? 2) Does the package work as communicated by the CMMS vendor and understood by the users? The scope of testing extends beyond just testing the software. It can include deliverables such as detailed user requirements, technical specification, design, documentation, and procedures.
Following is a brief introduction to the complex, laborious world of testing, with details on the steps required to properly test a new or upgraded CMMS and the types and levels of testing available.
Many people believe that testing a CMMS package means attending vendor demonstrations and “playing” with a demo version of the software before purchasing a new package or installing an upgrade. But proper testing requires at least as much work as writing a user requirements document. There is no limit as to how thorough your testing can be. The rule of thumb is that testing is cost-justified if the potential loss resulting from implementing a poor-quality CMMS exceeds the cost of testing.
Develop a test plan. A few hours spent up front developing a plan for how to approach the testing process will save considerable cost and aggravation. The test plan should encompass what needs to be tested when and to what level of detail.
When buying a new CMMS, two key milestones require testing. The first is before the selection of the CMMS, and the second is after a package is selected and before implementing a fully configured CMMS.
For testing prior to package selection, user requirements should be evaluated line by line to determine the appropriate testing required. There are three testing possibilities here: Category 1 testing, using the vendor’s data and procedures (i.e., a vendor demo); Category 2 testing, which uses the vendor’s data but your specified procedures; and Category 3 testing, where you provide your own data as well as the procedures. The third approach is by far the most costly.
Once a new CMMS package is selected or before upgrading your existing CMMS, a test plan that covers all processes and functionality supported by the software should be developed.
Prepare test scripts. When a user requirement calls for Category 3 testing, a test script must be produced describing the actions needed to execute the test and the expected results. Sample data needs to be supplied as well.
You may wish to provide the CMMS vendor with some recent equipment history data to see if the vendor can produce a certain report as specified in the requirements document. A sample report can be prepared showing what information is required for what purpose.
Generate entry/exit criteria. Before moving from one level of testing to the next, entry and exit criteria must be met. For example, a module will not go to pilot until all Severity 1 variances (i.e., deviations from user requirements) have been eliminated in user acceptance testing. Severity 1 variances can be defined as variances that have a significant negative impact on the ability of the maintenance department to meet its service-level commitments to the operations department.
Determine resource requirements. Human resources that may be required are testers, knowledgeable users, and technical experts. External resources required include representation from the CMMS vendor and any relevant partners. Other resources that need to be considered are automated testing tools, test equipment, a test lab (which might just be a conference room set up temporarily for testing), and vendor facilities.