I'm starting a new project testing a SAP implementation. Could anyone recommend any useful reading matter(books, URLs, articles) which addresses the testing implications for ERP. My knowledge level is low at the moment. My initial view is that an ERP application is a parameter driven application so it should basically work as long as the code parameters have been set up correctly. Does that reduce the test requirement in some areas, e.g. boundary values, concurrent updates etc. I'm not naive so I realise extensive testing will still be required to ensure it meets the business requirements.
Life should NOT be a trip to the grave with the intention of arriving safely in an cool and well preserved body, but rather to skid in, chocolate in one hand, beer in the other, body wrecked, totally worn out and screaming WOO HOO what a ride!
(Warning: Old Guy Ramble)Back in the old days of the 1980s when we called ERP applications by the name of "software packages", I did a reasonable amount of testing on package installations and upgrades - hopefully the same testing techniques will work on ERP applications today.
The bugs I found were of the following types:
* environment misconfiguration, e.g. wrong database name used, operating system did not have all the software patches applied, etc
* incorrect parameter value - due either to the analyst setting it up wrongly as they misunderstood/ were confused by the installation guide or they just plain overlooked it when they were setting up the package (caused about 60% of bugs)
* bad data - due either to the data conversion tool or to bad data already in the pre-converted database and the new software version was more strict in its data validation (caused about 25% of bugs)
* security setup - the various user roles did not have all their permissions enabled during setup.
* bugs in the software itself that the creators did not find before release (typically low except for Version/Release 1.0 of packages)
What I generally didn't have to worry about was data validation / screen navigation bugs so I used to omit that kind of detailed testing. If there were standard reports as well in the package then I would assume they did not need testing.
Hence my testing would jump over the unit/integration stage and go direct to function testing. It was normally organised around business transactions and setup to go from start to finish in the business lifecycle, e.g. from start to finish for a service order, from start of month to end of month for an accounting package. I would use the different user roles during this processing. What I tried to do was exercise all functions and all screens and all reports in my testing and check the results against the inputs to confirm they were "as expected". Test oracles are difficult with packages - somethings have to be taken on trust.
The other factor is user expectations. Many a user would say "it is a package, it doesn't need testing", grumpily start the testing and then hit bugs because the parameters were wrongly setup or they had misunderstood how the package worked - at this point they suddenly became testing supporters.