How to make a test strategy for a software package?
A testing strategy is an important step. In the context of implementing software packages, the testing strategy is one of the main pillars of an effective implementation approach. Indeed, tests must be carried out in every design of an ERP solution. A test strategy is an approach that promotes better risk management. In other words, testing a software package before it is implemented helps improve and optimize it. Why and how to make a test strategy for a software package?
Why make a testing strategy for a software package?
The testing strategy for a major project can include up to 15 different categories of tests. These different categories can be grouped into two main classes: solution tests and technical certification tests. Learn more about the 15 categories of tests in the table below.
A testing strategy adapts to the project. Because every project is different, every testing strategy will be different. It is therefore developed after analyzing all of the potential problems of a solution. More testing should be devoted to the parts of the solution that are most complex and in which defects would lead to the most severe consequences.
Throughout the execution of the testing strategy, business process experts and software package experts work together. The teams work on the preparation of test scenarios and their execution. Pooling the knowledge of business and software package experts is essential. Their collaboration makes it possible to achieve optimal parameterization of the software package.
How to make a test strategy for a software package?
Specialized test management tools are used in order to properly control the activities of each category and to measure their progress. These tools serve to manage test scenarios, results, follow-up on the resolution of anomalies and prepare accountability reporting.
All test categories will be executed in information-systems environments controlled by the project team. It is recommended that a total of eight environments, in addition to the production environment, be set up.
Throughout the testing process, it is important to provide an adequate level of technical support. A dedicated team of experts in infrastructure, operating systems, databases and software packages will be assigned to the project. This team will install hardware and software packages, ensure their administration and performance, apply the necessary patches and take care of backups and refreshing of the environments.
Test scenarios
The test scenarios prepared during the course of a project are an asset to be preserved and reused in subsequent projects to upgrade or add functionalities. They also serve as a basis for documenting business processes and developing user training material.
It is possible to accelerate the preparation of test scenarios by using a bank of predefined scenarios. Some software vendors and consulting firms have sets of test scenarios as part of their intellectual capital. These can be made available to their clients.
Investment in test automation is not always timely. This decision will be strongly influenced by the number of potential regression test cycles, the number of annual implementations and the nature of the tests involved.
A testing strategy must control every variable introduced during the different categories of tests. This makes it easier to isolate, diagnose, and resolve detected anomalies. The main variables encountered are infrastructure, software packages, parameterization, data and interfaces.
Changes to the configuration and parameterization of the software package must be managed by a central group independent of the test teams. Why should this be the case? To ensure that changes to configurations are carried out in a controlled manner and allow them to be replicated in a uniform and concerted manner in all environments. Finally, configuration control makes it possible to document the differences between test environments. The objective of this control is to minimize situations where it is not possible to explain why a software package behaves differently from one environment to another.
Jean-François Desroches is Program Manager at PlanAxion Solutions.
He can be reached at jean-francois.desroches@planaxion.com
About the Author
