Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 3 of 5

Lifecycle, triage and routing

8 min

Listen to this lesson

0:00 / 8:14

A defect moves through a set of states from discovery to closure. The exact names depend on the tool and the program, but the shape is nearly universal. What matters is that every state has an owner and a clear exit condition, so that no defect sits in limbo and nobody closes one without proof.

  1. NewLogged by the tester with evidence; severity proposed
  2. TriagedValidated, priority set, assigned to a team and person
  3. In fixAnalysis and correction in DEV; transport recorded
  4. Ready for retestFix transport imported into QAS; defect returned to the tester
  5. ClosedRetest passed with evidence; regression considered
A typical defect lifecycle. Side exits: rejected (not a defect, duplicate, works as designed) and deferred.
The Sign-Off Table · thesignofftable.com/academy/sap-tst-104

States and exit conditions

  • New: exits when triage confirms it is a valid, reproducible defect and sets priority and owner.
  • Triaged / assigned: exits when the fixer starts analysis. If the fixer needs more information, it goes back to the tester, not into a silent queue.
  • In fix: exits when the fix is built, unit tested in DEV and the transport is released, with its number recorded on the defect.
  • Ready for retest: exits only when the transport is imported into the test system, not merely released. The tester then re-runs the failed case.
  • Closed: the retest passed and evidence is attached. If the retest fails, the defect is reopened with the new evidence.
  • Rejected or deferred: requires a reason and, for deferral, an owner and a target date or release.

In SAP Cloud ALM, defects are created from failed test steps in the Test Execution app or directly in the Defects app, and are linked to the test case. SAP's community guidance describes a flow in which the processor moves the defect to in progress, sets it to retest required once fixed, the tester retests, and the defect is then closed. Status names and options can change between Cloud ALM releases, and tags can be used for finer sub-statuses; check your tenant's current list.

Triage

Triage is a short, regular meeting (daily during intense test cycles) that looks at new and stuck defects. Typical attendees are the test lead, the functional leads for affected areas, a development lead and, for priority decisions, the process owners or their delegates. Triage confirms each new defect is real and not a duplicate, sets priority, assigns an owner, and reviews defects that have aged beyond their target. It is not the place to fix defects; it decides who will.

  1. Review new defectsReal and reproducible, or a duplicate?
  2. Set priorityWeigh business urgency with the process owner
  3. Assign an ownerRoute to functional, development, security, integration or data
  4. Review aged defectsChase defects past their target age
  5. Close the meetingDecisions recorded on each defect; nothing is fixed in the room
Triage follows the same short agenda every time: validate, prioritize, assign and chase, without trying to fix anything.
The Sign-Off Table · thesignofftable.com/academy/sap-tst-104

Routing to the right team

SymptomLikely teamContoso example
Wrong price, tax, account or output from standard configurationFunctional team for that areaRevenue account determination for fleet billing
Short dump, custom field missing, enhancement logic wrongDevelopmentFleet contract check enhancement raises a runtime error
Missing authorization message, user cannot open an appSecurity and authorizationsBilling clerk role lacks the app needed to release billing
Message not sent or received, mapping wrongIntegrationElectronic invoice to Great Lakes Fleet Services rejected by partner
Missing or wrong master data from the loadData migrationProduct CMC-ALT-100 lacks plant data for 1720
Suspected error in SAP standard codeFunctional or development lead, then SAP via an incidentStandard app behaves differently from SAP's documentation

Routing by symptom. The first guess may be wrong; triage reassigns quickly rather than letting a defect bounce.

  1. Does analysis point to SAP standard code?Yes → go on · No → route to the project team that owns the area
  2. Is there an SAP Note with a known correction?Yes → apply it in DEV and transport it like any fix · No → go on
  3. Has a lead raised an incident with SAP through SAP for Me?Yes → record the incident number on the defect · No → raise it now
  4. Has SAP's correction been applied and retested in QAS?Yes → close the defect with evidence · No → keep it open
A suspected SAP standard defect goes through SAP Notes first, then an incident, and stays open in the project until the correction is retested.
The Sign-Off Table · thesignofftable.com/academy/sap-tst-104

What would you do?

A developer marks defect 214 as "fixed" and sets it to ready for retest. The transport has been released in DEV, but the next QAS import is tomorrow night. What should happen?

Key points
  • Lifecycle: new, triaged, in fix, ready for retest, closed; with rejected and deferred as reasoned exits.
  • Ready for retest means the fix transport is imported into the test system.
  • Closure requires a passed retest with evidence; failed retests reopen the defect.
  • Triage validates, prioritizes and assigns; it does not fix.
  • Route by symptom to functional, development, security, integration, data or, via an incident, SAP.

Check your understanding · not graded

Lesson check

  1. 1. When is a defect truly ready for retest?

  2. 2. What must happen before a defect is closed?

  3. 3. A user cannot open the app needed to release a billing document and sees a missing authorization message. Which team should get the defect?

  4. 4. What is the main purpose of a triage meeting?