ERP Testing: Surprising Developments

Having read the latest ERP Project Manager Diary on Talent Puddles and Turnips. I couldn’t help but add my thoughts on what is already a wonderful diary of the experiences found in an ERP implementation.

Our project manager wrote: “In a surprising development, I crashed the test ERP system today”. I thought about this and wondered why the development would be surprising. In my own experience ERP testing is not thorough enough. It is running in a test environment so there is almost no chance of damaging our currently used systems. We frequently test used transactions and typical reports, and that is all valuable. But why not test that once-a-century problem we ran into last year? It caused us a lot of grief then and would cause at least as much grief if we ran into that situation again with the new ERP.

Maybe we should reward our team members with attaboys when they break the ERP system. Every time they do this in ERP testing is one time it won’t happen for real when it really hurts. Test those rare transactions. Try to think of some off-the-wall situation and see if your ERP system passes that test.

What happens if we enter a sales order with no customer? Will the ERP allow us to build and ship something we cannot produce to a non-existent customer? What will stop us from ordering phony materials and paying off the buyer with real money? I know this is a typical fraud but maybe we could have a warning of some kind to help prevent this sort of situation.

So, put your ERP software to some real tests. You might discover a bug the vendor hadn’t discovered yet. You might also find the ERP vendor stumbling to explain whatever logic was used in developing the program. But you will know if the problem can be avoided completely or if you need some non-system awareness to trap the problem.

Another useful test is to overload the system with too many transactions and reports and queries all at once prior to *ERP go-live. Sure, it runs well in your test environment with only a few users who are working part time on the project. What will happen when everyone gets online and wants to run complex queries at the same time? Hopefully, it all works with such a slight delay no one notices. But “hopefully” is not a word that should appear in the lexicon of ERP testing!

ERP testing might be the most important phase of implementation. Test the system hard. When you exercise, you sweat, right? Make the computer sweat too!

author image
Tom Miller

About the author…

Tom completed implementations of Epicor, SAP, QAD, and Micro MRP. He works as a logistics and supply chain manager and he always looks for processes to improve. He lives near San Francisco Bay in California and can be found on the water in his kayak or on the road riding his motorcycle. Contact Tom at

author image
Tom Miller

Featured white papers

Related articles