Testing

I spent a fair amount of time on SAP implementations, and testing was always one of those areas that people talked about in the project plan but never really thought through until something broke. So here is a review of some testing practices I encountered — what worked, what did not, and what I wish someone had told me earlier. Methodology Matters (Even If You Think It Does Not) Every SAP project has a methodology. Sometimes it is a proper one — Deloitte’s Thread Manager, IBM’s Ascendant, SAP’s own Roadmap through Solution Manager. Sometimes it is “we did something similar last time, let’s do that again.” Sometimes it is nothing at all, and the project is winging it. ...

This is the process I follow on projects. It’s not fancy, but it works for me. Defining the requirements. Write down what needs to be built. Be specific. Ambiguous requirements are the root cause of most problems later on. Approval. Get sign-off on the requirements before anything else. If the requirements change later, that’s fine, but do it deliberately, not by accident. Template designs. Work out the structure and layout before writing code. For web projects this means mockups and wireframes. For other projects it means architecture diagrams and data models. Template approval. Get the designs signed off too. It’s cheaper to change a design than to change code. Coding. Build it. Internal release. Get it in front of the team first. Internal testing catches the obvious stuff before anyone external sees it. Testing. Proper testing, not just “I clicked through it once.” Automated tests where possible, manual where necessary. Alpha release. Early access for a small group. Expect bugs. The goal is to find them in a controlled environment. Beta release. Wider release. More users, more edge cases. This is where you learn what people actually do with the software versus what you thought they’d do. Project goes live. Production. The real world. The key thing is not to skip steps. I’ve seen projects that jump straight from requirements to coding and then spend three times as long fixing problems that a proper design phase would have caught.