Testing is a very important and critical activity in the ERP implementation process. At this stage, after the prospective user project team understands how to use the system.
So, one of the keys so that we can successfully implement the ERP system, we must do the testing completely and correctly.
System testing is especially important when we do custom development, if the system is made specifically for your needs, it means that the system has never been used by anyone at all.
Therefore, the time needed to prepare for testing must be more than when we buy applications that are available in the market.
In order for us to better understand the importance of testing, here are the goals:
- To test/verify the process of a system working as agreed in the blueprint
- To test/verify are the results as expected? Is the calculation method correct?
- To test / verify in case there are some unplanned cases or exception.
First of all, we have to do a unit test. And as the name implies, in unit tests we are more focused on testing a function in the system to be tested.
For example, we create a system for sales, then we have to test:
- Customer master data.
Are all the required data available? Customer Code, Customer Name, Customer Group and more. Was everything saved successfully at the time of data input, and can you access it again?
- Sales Transactions.
When entering sales data, can all the required information be accommodated? Customer Code, Item Code Sold, Number of Items, and Price of Goods? Is a discount possible? How is the discount calculated? How do I enter sales tax information?
When doing a unit test, we need to check all the data for completeness, and are all the calculations such as the value of a discount or tax, can give the result as expected.
In both examples, it can be seen that our focus when performing Unit tests is more on one particular function. To test the completeness of information, and whether it is in accordance with our expectations when it is run.
After we go through the unit testing stage, then we have to do the Integration test stage, where in this activity we carry out continuous testing.
The testing process has also involved several related divisions that will use the system.
If you could say we did a simulation at the integration test stage, we were trying to condition what happened when the new system was used.
If in the unit test we have to make a list of what we will test, then at the integration test stage, we have to create more scenarios that we will test.
For example, we do some testing scenarios for sales:
- Sales with one-time delivery of goods.
- Sales with partial / gradual delivery.
- Sales by Cash Payment.
- Sales with 30 days Credit Payment.
- Sales with Payments in stages.
Same with unit testing, with the existence of documented testing scenarios, it will be easier to perform testing and avoid business processes that are overlooked by testing and only realized when the system is used.
PERFORMANCE TEST / VOLUME TEST
Finally, what we usually encounter when assisting the ERP implementation process, apart from the bugs that can be found during Unit test and integration test, are Performance problems.
Sometimes when we do the Unit test and Integration test, this problem is not visible considering the number of users who do the testing is only partially included in the project team where only about 20-30%, but when all users use the system, the system response can be slow. Other things can also happen because at the time of testing we were only using sample data, we had not used 100% of the actual data so that the system performance response was not visible.
In the testing phase, we must be able to predict the performance of the new system that will be used.
Do you prepare the time to do testing simultaneously with all teams within the company including those outside the ERP implementation project team?
We must also take into account if the amount of data will be a lot more than what we have used during testing.
As much as possible, do simulations, especially in certain business processes, which we already knew at the beginning of project preparation, would be a challenge.
For example, in a retail project that we have handled, the customer has more than 1 million item master data. During the testing stage it’s impossible for user to have completed all of the data, and for the purposes of the unit test and integration test by only preparing 10 thousand item data. That’s already more than enough.
Imagine the difference between testing using 10 thousand item master data and the condition later when the system is running with 1 million item master data.
Project management must be very clever in strategizing how we can simulate a number of things that might interfere with system performance when the system starts to be used (go live).
Of course, it’s not that we want everything to be ready when we do the project preparation, but when the system starts to be used and performance problems occur, the system cannot be used so it will interferes with operations.
The tendency of the team members when doing testing (which should be testing the system), but because the system is new and needs adaptation, they spent more time doing learning / training rather than testing.
Therefore, it is important to make a list of what we want to test (Unit Test, Integration Test and Performance Test), so that:
- We can understand the how many things that we have to test
- Having a list of processes that are expected to be used while the system is running (go live), allows us to focus on testing, and have nothing to miss. And we just realized when the system has been used which can have fatal consequences, because when the system is used, it is more difficult to make changes where every change must be re-tested.
- By looking at the test results, we can analyze anything, ready for the system that is being built, from these results we can also make a more rational decision whether to use the system on schedule? Or project school? And for how long?
Therefore, without a list of what we have to test, whether it be the Unit Test, Integration Test or Performance Test, there will likely be chaos when the system is used (go Live).
In the discussion about whether we will use parallel run strategy or cut off the old system when the new system start, we question the readiness of the system because of fear that something will happen to the new system, or the new system is not yet suitable when it is used which will cause obstacles in daily operation.
By doing the testing repeatedly and completely, this risk can be eliminated.
Given the amount of activity that must be done during testing, it is again very important to get a commitment from the top management to give attention and time to support potential users.
Given this activity, prospective users have to spend a lot of time doing testing, and at the same time, not a few are still doing daily operational activities.
7 other key points that influence the success of ERP system implementation: