Organizing test sessions for ERP projects or testing ERP software is certainly not an easy feat. ERPs are complex in the sense that they comprise many system modules that need to be tested both in isolation and as a whole to ensure that the all-round capabilities of the system are satisfactory.
To simplify testing on our ERP project, we categorized the tests to be conducted into the underlisted areas. Software tests in general, are certainly not limited to any of these categories.
1. Unit Testing: This refers to a stand-alone testing of the system after modifications (e.g. introduction of custom code) and it is performed after development, by the developers. Any custom code introduced into the ERP software should meet the basic requirements of the business and be devoid of bugs. A unit is the smallest testable portion of software code e.g. procedures and classes.
2. Feature Testing: This refers to a stand-alone testing of the system configuration/functions.
3. System Testing: These tests will verify system features and functionality independently and it is useful in confirming that the overall setup and configuration of the system generally meets the needs of the business. This test will typically be carried out by analysts or project team members who understand the requirements of the business.
4. User Acceptance Testing (UAT): This will be the final testing performed by key users. The UAT may be process or module-based and should cover testing of all the roles, reports and access rights that will be available to each configured role to ensure that a user is not given more access than is required.
This category of tests provides a chance for users to identify any major issues that may prevent go-live.
5. Performance Testing: This type of test focuses on simulating the high transaction volumes that is anticipated during peak times. It can help to verify that system performance meets business requirements by checking that the configured system will perform acceptably under heavy load. Will the remaining bandwidth be enough for other users once the ERP is in full use? Performance tests should be carried out on all platforms where the ERP will be used (e.g. web/client).
This test is about throwing as much load as possible on the system to be sure that it can handle high transaction volume.
6. Data Acceptance Testing: Testing performed not only to verify that data is migrated completely and accurately but also to validate that the data may be inquired upon, reported upon, and transacted upon.
7. Cutover Testing: This is the testing performed to ensure that data is adequately transformed and migrated to the new platform. It ensures that all the activities that need to be performed before moving to the new ERP system are clearly marked with their results validated.
It also includes conversion activities that must occur in precise steps before go-live.
8. Interface Testing: This category of tests are done to ensure that interfaces that plug into the ERP encounter no difficulty sending or receiving the data that is needed for transactions. Examples that fall into this category include interfaces with banks, regulatory authorities or other interfacing software systems for which connections are required.
If you are trying to reduce complexity and stick to the minimum amount of testing that is required to bring the software system live or one that is capable of reducing project risks to an acceptable level, this list can serve as a useful starting point.
Picture Attribution: “Online Software Means World Wide Web And Website” by Stuart Miles/Freedigitalphotos.net