The Testing Phase: Rights and Wrongs
As a project implementation Mentor to SAP Business ByDesign partners, I am lucky enough to get an insight into how different partners approach this topic.
The verification phase of a Business ByDesign project should be the time where the partner can take a step back and watch the customer/end users validate the business processes already delivered and configured during the realise phase.
To make the testing phase a success here a few tips that all partners should look at, and some practices that are best avoided!
Make Testing a Success
- Before any testing starts, validate that you have created or migrated all the necessary foundation and dependent data. SAP provide an accelerator for this; Data Migration Scope and Planning Document You cannot test an integrated ERP system, without all the data. I guarantee there will be errors/warnings otherwise.
- Use a testing plan. Make sure as the implementation partner you have decided what the expected result for each test is, and that the outcome is consistent each time you test. We provide an accelerator for this too .ByD Test Plan
- Remember – Testing isn’t training. You should always ensure that users know how to navigate the screens and understand the basic process they are testing. SAP supply a learning content area inside the ByDesign help. And of course all the help is available here
- Always test using an Employee Log-in not a service agent. Normally the service agents you create when building the system are not assigned to org units, have no line manager and are not part of any workflow you may have set up. A good example is when running reports, if you have the currency set to “Default Company Currency” then run the report as a service agent, the currency is likely to be USD rather then the company currency, because the service agent is not assigned to a company!
- If possible, don’t activate any approval processes until you have tested and validated the core business process. In my experience approvals can cause complication and confusion to new users who are trying to test their own business process. I find it much easier to test the process, validate it and then turn on the approval process. You can then just test the approval as a separate stage in the testing plan.
Make Testing a Failures
The biggest mistake I see partners making when building ByDesign systems, is trying to test too early. By this I mean before all the fine tuning exercises have been completed, before foundation data is created, and during the migration process of dependant data. This leads to fixing errors as you go in a rather piecemeal approach. This is both time consuming and an inefficient method. errors will be made, mistakes will creep in!
It is much better to ensure the fine tuning is as complete as it can be. All the data (upto transactional data) has been created/migrated and then start the testing.
Lesser mistakes include
- Testing as a Service Agent – always use employees
- Using “any old data” or made up data – don’t always check with your customer to supply real examples of the data they would be creating.
- On this subject I hate to see data like “Mickey Mouse Trading”, “Donald Duck” etc don’t use comic data it doesn’t look professional.
- not using the test scripts – or worse not having a defined process.
- I see this a lot, please communicate how the process has been configured to work – so the outcome can be predicted
- Be aware that users without a process will test things that in reality will never happen! So no system could be prepared. For example trying to sell “raw material” items that are only ever part of a BoM.
This isn’t an exhaustive list by any means and I welcome comments from customers and partners on what makes for good (and bad) testing.