An anomaly is a difference between the expected behavior and the actual outcome of a test. This is registered so that the cause can be analyzed and resolved. In SAP projects, often an anomaly is called a defect, but because this term can be very confusing, we use the term anomaly as specified by the IEEE 1044 standard. Synonyms commonly used in SAP are Defect, Issue and Bug.
The process of identifying, investigating, and resolving anomalies is known as anomaly management. An anomaly must be investigated and when the cause of the problem is found, it can be fixed. If the problem was caused by a fault in the IT system, then a change to the IT system (and/or the data) is needed. If the anomaly was caused by a fault during testing, then the test must be changed.
After fixing an anomaly, the test involved is retested to confirm that the fix has solved the anomaly. At the same time, a regression test is often done to confirm that the fix did not introduce any new problems. Apart from improving the product, anomalies are also an important source of information for improvement of the processes and the people involved, especially to prevent similar anomalies to arise in the future.
When the fix of anomalies found during SAP testing is not possible as part of the sprint, anomaly meetings should be held to discuss possible actions:
- Prioritize the resolution of the anomaly: Assess the business impact and prioritize it accordingly. If it is a critical problem, consider moving it to the top of the backlog and addressing it as soon as possible.
- Workaround: Develop a workaround to temporarily resolve the problem until the fix is implemented. Or consciously decide, with the appropriate stakeholders, to make it a permanent workaround and not fix the problem.
- Defer the fix: If the impact is low defer the fix to a future sprint.
- Escalate the anomaly: If the impact of the anomaly is significant, escalate the anomaly to the appropriate level of management for a decision on how to proceed (like a dispute meeting).
- Update stakeholders: Keep relevant stakeholders informed of the status and action taken to resolve it.
The goal of anomaly meetings is to bring the right people together to assess the impact of the anomaly, prioritize it, and work towards its resolution. Participants to include in anomaly meetings:
- Project Manager (or Product Owner in Agile teams): To ensure the resolution is aligned with project timeline and budget.
- Business key user(s): To provide a functional perspective and to prioritize anomalies based on their business impact.
- Development team representatives: This includes both ABAP developers and functional developers. ABAP developers provide a possible technical implementation of the solution, technical feasibility of the solution and effort required to resolve the issue. Functional developers provide the perspective on functional design and configuration related changes if needed.
- Testing team representatives: To provide detailed analysis of the anomalies found during testing and to provide an estimate of retesting efforts related to the fix.
- Scrum Master: May or may not be required, depending on the specific circumstances of the project.
The purpose of anomaly management is to fix problems but also to provide information to improve the IT delivery process. It is important in the continuous monitoring of product quality throughout the whole lifecycle of the product.
Anomaly management in SAP projects is different from other projects in the following ways:
- Systems are often customized according to specific business requirements.
- SAP systems integrate with multiple other systems.
- It may be difficult to isolate the root cause of an anomaly and determine its impact.
- Correct working of an SAP system also heavily depends on quality of (test) data.
Anomaly management should be supported with tools. Usually these are Test Management tools.