SAP Testing – The missing key to your successful SAP Implementation
If there is one key to a successful implementation, it is simply this:
Duh. Well that’s obvious. Well if it’s that obvious, why do so many implementations fail to do a decent job of it? It just amazes me, the number of times that I am standing behind a user doing go live support, and something does not work. Often, this is Day 1 of go live. Was this not tested?
What Types of Testing are there?
Through the years, I have compiled the following list of testing types that must be done.
Ignore any of them, at your peril.
This can and will cost you a smooth implementation and a lot of money.
Users will hate the system, politically, it will not be seen as a success and the costs to fix things can literally go on for years.
Just when you thought the cost of implementation was over, it will go on, and on, and on..
You get the idea.
Look carefully at this list. Notice one thing: the types of testing, generally correspond to the phases of a project and they are often done by different groups of people.
Does the application work as designed? This can be a standard SAP business process or a customer specific extension of the code. It can be executed by any team member or the users.
This is also known as horizontal testing. Does the process work on it’s own? Ignore all integration. Is it doing what it should be doing on it’s own? In Sales and Distribution (SD), this may be from order to billing.
This is also known as vertical testing. After unit testing is successful, does the module or process integrate correctly with other modules (example: If it posted to Financials, are the postings correct?)
This is crucial. The most successful implementations always second some key users to the project (and backfill their positions temporarily). And note that testing for a single week will generally not cut it. It will require longer involvement and possibly ongoing involvement by the user(s). Users always find things that project members miss or never thought us. Lets face it, they use the system every day.
The old tongue in cheek joke is: “Without Users, this system would be perfect”.
But in truth, their involvement and sign off, is crucial to your successful implementation.
Remember, as far as they are concerned, this is just a “dumb tool” to help them do their jobs.
Management may be looking for the statistics and the integration.
The user does not care !!!
All he/she wants to know is: “Will this help me do my job better?”
That’s been my experience. Everybody wants to do a good job. There is nothing worse than having a tool that makes my job difficult.
In the past three years I have been working in Call Centres. So I have become acutely aware of performance. In one of my clients, a key metric was a 20 second order (we had to built a custom front-end to order entry)!
In other client, we spent a year developing a custom solution to track freebies, put it in production, and then discovered that the “nightly” job run, ran for seven days !!! It took us another 4 months to get the same program to run in 7 minutes !!
Often performance testing is neglected or poorly done. And if you are running a multinational roll out, you had better get it right.
A lot depends on your development environment here. Do you have a box with enough “live” data to test on. And how close does this match your production environment?
In the last few years I have been involved in the medical devices industry with several clients. They have to comply with the FDA and run so called “validated systems”. In the last four or five years, SOX has also been a huge impact to SAP implementations. So I have become painfully aware of the need for both doing and documenting regression testing. It has always been done, but the need to document it has not always been required.
What is it? Simply put: If you change anything (a configuration setting, a process, a program), you have to test everything related to that change.
Integration is one of the massive advantages in SAP. But it can also be curse when you are making changes. Because by changing a small thing, you can effect everything. All implementations learn this, usually the hard way.
An recent client told me this story. A change was made. It was tested in the test environment, integration environment and again in the staging environment. Everything looked great. They promoted it to Production.
Production crashed !!!
The system was done, worldwide, for 3 days !!!
Turns out, that it was an Oracle bug, which only showed up in a multiple application server environment. None of the testing nor development systems had multiple application servers – They never do. So you just never know.
This is a type of regression testing and refers particularly to an upgrade. Take your time here. Things break in upgrades. Particularly if you have many custom programs. Or you use GUIXT to make screen changes (by default it identifies screen fields by their description. So if the SAP description changes in an upgrade, it will not work. Easy to fix).
Who should do the Testing?
This is key. Not all of us are good testers, period. To be a good tester, you need to be detail orientated. People have said that I am a good tester. But, to be honest, I am an OK tester. I know what needs to be tested, but I can only handle a certain amount of detail before it drives me nuts. Find people who love “breaking things”.
Make sure you identify uses with these characteristics too. Better yet, if they are in responsible positions (head CSR,..). They will have to answer to their fellow colleagues, why the system that they tested, does not work properly or makes their jobs difficult. In my last implementation, there were five people (rare) on my team who were excellent testers. I knew that if I wanted some of my work tested, to give it to them. They always found stuff that I had missed.
I am covering this not because it is typically done, but because it is typically not done. Clients do not want to spend the money. But, long term, this could save you a fortune. Now it is not easy and requires an initial investment to set it up. And a smaller ongoing investment to maintain. But the long term value is enormous. Think about this: Typically, an upgrade can take 3 months if you have an average amount of custom code (most of my implementation have a lot of custom code). And most of that time is spent testing. And it requires a team of bodies. What if you knew exactly what had to be tested and could run a series of automated test scripts, to tell you in a few hours, what had broken? How much time and money would this save?
Remember, most of us are not good testers. And if it is not your strength, you often miss stuff, and TAKE LONG. So by using good testers to set up the tests initially.
If you found this article informative, feel free to add comments to my blog. And pass it on.