Today I would like to extend defect management topic and show how you can manage Defect Corrections (DC) with the help of Features in SAP Cloud ALM.
Focus of this blog are green-marked activities within E2E implementation process in SAP Cloud ALM – test execution and processing of defects:
End-to-End Implementation Process in SAP Cloud ALM
Prerequisite
You leverage Change & Deployment Management capabilities of SAP Cloud ALM and deploy the changes through your implementation landscape with the help of Features.
Defect Processing in SAP Cloud ALM
Defect Management is crucial part within Application Lifecycle Management, and aims to operate defects, created for deficiencies that were discovered during test executions or in the live application.
Whilst Defect documents a deficiency, Defect Correction (DC) contains technical correction of affected object.
Defect Correction (transaction type might also be known to you from SAP Solution Manager and Focused Build) is typically used during integration test phases to support defect resolution process.
Currently in the SAP Cloud ALM there is no Defect Correction as a separate entity, however we can leverage Features for this purpose.
In this post I am going to describe possible process flows for Defect Corrections, which should support resolution of Defects created during test execution and trigger re-test activities.
In other words – if you are already familiar with test management process and defect processing in SAP Cloud ALM – what happens behind the scene, before Tester gets Defects back in status ‘Re-Test Required’ 🙂
Important note: there is currently no direct connection between Defect and Feature objects (please check related Roadmap Item), however both objects can be linked with each other via ‘References’ and this is a way how I recommend process handling. Please follow below for more details.
Process Flow options
Defect processing in SAP Cloud ALM is quite simple and follows quite straight forward process.
In practice collaboration model between Testers and Defect Processors (Developers, Consultants) may vary. Detailed process flow depends on your organizational structure complexity – especially while working with distributed teams or using various project implementation and testing approaches (agile framework / ‘whole-team approach’ etc).
By saying that I mean that Testers may not directly know the Developer responsible for the implemented change and can therefore first assign a ‘Responsible’ in the Defect, who will then dispatch it to a necessary processor.
From experience – such distribution task could be taken by Test Coordinators within workstreams or even Development Team Lead, who distributes Defects among team members and prioritizes them in the backlog.
Here comes first possible process flow for defect management including defect corrections, if you have support from Defect Dispatcher:
Below comes simplified process flow, when organisational / team structure is not complex, and Testers assign Developers / Consultants directly as processors:
You may have a question – why not to assign a Team to a Defect?
Surely it is possible, however notifications are being sent from SAP Cloud ALM only to entered ‘Responsible’, this is why I would recommend working this way, as it will accelerate defect processing.
Tips for handling in SAP Cloud ALM
To support process presented above, following apps in SAP Cloud ALM are used:
As you have already noticed above, there is currently no direct connection as well as no status inheritance between Defect and Feature objects.
To get a better traceability in defect correction process we shall link both objects with each other via ‘References’:
2. Feature (DC) with Defect:
Such reference link is easy to handle and in case you need to navigate to related Defect from Feature or vice versa, a new tab will be opened directly for the linked object. References will not pop up in reporting, however for Project & Test Management it could be helpful to get an overview on the Defect Corrections (Features) via Project Overview, Features or in Analytics apps.
To distinguish between Features, which support implementation process and those for Defects resolution, I would recommend using tags, e.g. ‘Defect Correction’:
Authorization concept
What should additionally be taken into consideration is your authorization concept in SAP Cloud ALM. Please refer to the current state of roles and authorizations needed for Features (actions, statuses).
To be able to follow described processes and change statuses of Features (Defect Corrections) to ‘Successfully Tested’ or back to ‘In Implementation’ if re-test fails, Testers should have additional roles.
Is it also possible to operate only on Defect level for Testers. They can change the status back to ‘In Progress’ if re-test fails and Developer will take care of Feature status processing.
There is a lot of flexibility SAP Cloud ALM provides you with.
External API Management
If you have external tools in your IT landscape and would like to have a defect workflow configured outside of SAP Cloud ALM, it is also possible using External API Management under ‘Subscription’ tab of the project:
Follow the application help for more details.
Conclusion
Test activities are always executed in an iteration with defect processing.
Leverage the defect corrections in SAP Cloud ALM and benefit from holistic process orchestration within one tool.
Useful links:
Stay up to date with the planned functionalities in SAP Cloud ALM by checking product Road Map.
Learn about Defect Management in SAP Cloud ALM – technology blog
Demo Test Execution and Defect Management – video (4 min)
SAP Cloud ALM for Implementation – Application Help
Using Transport of Copies in SAP Cloud ALM – technology blog
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
12 | |
12 | |
11 | |
8 | |
7 | |
7 | |
5 | |
5 | |
4 | |
4 |