Linking to features and tests

A requirement and its user stories describe the change. Two more links make it provable. The feature ties the change to the transports that carry it through CMD, CMQ and CMP. The test cases tie it to the evidence that it works. When both links exist, Priya can answer the release manager's question ("which tested changes are in this deployment?") and the process owner's question ("is my requirement tested?") from the same data.

Features: the unit of deployment

SAP describes the feature as the mechanism for deploying changes across the landscape. It is a change record and orchestrator, and the container for transportable objects. SAP's guide adds the rule that matters for traceability: a feature can encompass several user stories but can be assigned to only one requirement. In the leading practice for private edition projects, the relationship is one-to-one: one requirement, one feature. The incremental variant allows several features per requirement for staged delivery, at the cost of more complex testing.

Features follow their own status flow. SAP's learning content lists Not Planned, In Specification, In Implementation, In Testing, Successfully Tested, Ready for Production and Deployed, and limits which transport actions are allowed in each status. SAP's best practice deck labels one step Ready for Deployment; the wording varies between releases, so check your tenant. The principle does not change: the feature reaches "successfully tested" only after the tests linked to its requirement have passed in the quality system.

Assigning test cases

SAP's guidance says test cases can be assigned to the requirement, to user stories, or to both. That flexibility is useful, but a project must choose a pattern, because coverage reports count what is linked. Contoso's rule is simple:

• Requirement level: the end-to-end acceptance test the process owner signs, written from the acceptance criteria captured in the workshop.
• User story level: narrower functional tests for a story, such as the approver determination for a single purchasing group.
• Process level: standard process test cases generated from solution processes, which cover what the requirement did not change.

Defects and features

Defects raised during execution link back to the test case and so to the requirement. A Cloud ALM defect has a fixed, deliberately simple status set: New, In Progress, Retest Required, Postponed and Closed. When the fix is in CMQ, the processor sets Retest Required and hands the defect back to the tester who raised it. SAP has also been adding relations between defects and features, so the correction for a defect can travel in a feature and a release manager can see open defects on the feature before approving deployment. Check what your tenant offers; where the relation is missing, the same answer comes through the requirement.

Common linking mistakes

• Creating the feature before approval: transports start moving for scope nobody has agreed. Create features once the requirement is approved.
• One feature for a whole workstream: convenient for the developer, but every requirement in it is then deployed and tested together, and one failure blocks them all.
• Tests linked only to stories: the process owner's acceptance test never exists, so UAT has nothing to sign against.
• Custom code with no requirement: adapted ECC objects that Kenji's team fixes for the conversion still need a requirement or a story under one, or they are deployed untraced.