jump to navigation

Why do you need ERP System Testing? 05/23/2012

Posted by TBoehm30 in ERP.
Tags: , , , , , , ,
1 comment so far

Testing is one of the first items that are removed from a project when time becomes tight.  Many people wonder why they have to spend so much time doing formal testing when they have spent so much time training with informal tests.  They have spent so much time with the new system that they just know it works.  What is the point of spending a large amount of time on formal system testing?

First and foremost, you need to validate that you are getting what you think you are getting.  A new ERP system is a large complicated piece of software.  Just because individual sections are working, doesn’t mean that each module is sharing data the way it should.  A plan for system testing should include many of the core team, so they can see the larger picture.  You also need to be sure that the right communication is happening between team members.

You need to make sure that when a PO is created and received, that the inventory is added correctly and the journal entries are made appropriately.  You should review the documents and reports generated from the process to make sure that everybody is satisfied with the results.  When the PO is tested separately from the accounting module, it seems to work fine.  However, did anyone from accounting notice that the manufacturing group has automated the POs for inventory differently than expected?  This would be found in System testing with good communication between core team members.

You need to be absolutely certain that each process is testing using the same parameters.  There could be hundreds or even thousands of parameters in a good ERP system.  These parameters should be set based on the way your company does business.  For example, FIFO, LIFO, or Standard should be set to account for product costs.  I have seen software fail because no one realized that parameters were different than expected, or were changed during go-live.

The CYA reason for system testing applies for consultants and/or public companies.  A team who delivers a working ERP system takes a large risk of someone coming back with complaints.  Users can always find something to complain about.  A full, well documented, system test will reduce the risk for the implementation team.  If they have tested every scenario possible, then any complaints should already be documented and signed off. 

Auditors may be allowed to review the implementation process, especially if something goes wrong because of the software.  A good system test would be enough to hand over to show that you did everything you could think of to prevent problems.  When problems occur, you should be able to point to the system testing documentation to show that something new or different has occurred to cause the issues. 

Problems that arise after the system has been in use could become very large problems.  It is much better to find them early on.  A small problem could grow into something much bigger over time.  A problem that is found after a time lag will be more difficult to find and could be more difficult to fix.  System testing should be designed to follow all your processes to a logical conclusion.  If you are using the system for accounting, then journal entries and account balances should be watched during system testing.  If the software is used to run a call center, then you need to run rollup reports containing all possible call types.

IT projects are constantly delayed and have scope cut to meet deadlines or budgets.  A user will be much more forgiving of a delay in a project than he would for bugs in the software.  A problem that should have been caught in testing will be remembered far longer than any scope issue or delay.  Users will grumble and gather to complain about the software, keeping the errors at the top of their mind.  Delays, however, will be forgotten as the software finally comes out to make their lives a little easier.

A good system test will prove that you have done your job well and completely.  You can be positive that the system meets the requirements you were given, and you have documentation to back that up.  You will be able to move on to the next phase of the ERP system, or move on to your next project with confidence.  You know that it’s a global world, and Technology makes it happen.

Have you been involved in a project where testing was shortened, or removed, to the detriment of the company?  Leave your comment below.