Lesson 3 of 5
Defects
8 min
Listen to this lesson
When an action fails because the system is wrong, the tester records a defect. In Cloud ALM, defects are created from the test run, so they arrive already linked to the test case, the run, and the process. That link is what lets the test lead see which processes are blocked and what to retest when a fix arrives.
Creating a defect from a run
- In the run, select the failed action (or the run as a whole) and choose to create a defect.
- Give it a short, specific title: what fails, where, with which data.
- Describe expected versus actual, steps to reproduce and any error message; refer to the evidence on the action.
- Set the priority and the responsible person or team, and a planned completion date if your process uses one.
- Save. The defect is linked to the test case and run, and the action shows that a defect exists.
- Failed actionTester rates Fail - Application Issue in the run
- Create defectFrom the action, so it links to the test case, run and process
- DescribeSpecific title; expected versus actual; steps; error text; evidence reference
- RoutePriority, Responsible person or team, planned completion date
- SaveDefect linked; the action shows a defect exists
For automated test cases, defects are created from the test case list rather than from inside a run. Defects can also be created or updated in bulk by spreadsheet upload, which is useful when importing findings from a workshop.
Create new or assign existing
If the same failure appears in another run, for example the same pricing error in two order-to-cash test cases, do not create a duplicate. Cloud ALM lets you assign an existing open defect to the new run. One defect, two blocked runs, one fix, two retests. When a new run of a test case starts, open defects from the previous run carry over, so the link to the outstanding problem is not lost.
- Is the failure caused by the test case itself?Yes → rate Fail - Test Case Correctness; send to the author · No → continue
- Is there already an open defect for this failure?Yes → assign the existing defect to this run · No → create a new defect from the action
- Does it block other tests in the plan?Yes → set high priority and tell the test lead now · No → normal triage
Defect attributes and workflow
Defects in Cloud ALM are a kind of task, so they share task attributes such as priority, effort and due date, and they can be split into sub-tasks. The status set is deliberately simple: SAP community material describes New, In Progress, Retest Required, Postponed and Closed, and notes that the status list cannot be customized; teams use tags to simulate sub-statuses where needed.
Cloud ALM does not impose a severity model. Agree your own before SIT starts, map it onto priority, and write it into the test strategy. Contoso uses four levels:
| Contoso severity | Meaning | Example | Cloud ALM priority |
|---|---|---|---|
| S1 Critical | Blocks a core process; no workaround | Billing documents fail to post to accounting | Very high |
| S2 Major | Wrong business result; workaround exists | Fleet price not applied; manual override needed | High |
| S3 Minor | Inconvenient; result is correct | Field label unclear on output form | Medium |
| S4 Cosmetic | No business impact | Typo in a message text | Low |
A severity model mapped to Cloud ALM priority. Adapt to your program.
What would you do?
In UAT, three different Contoso testers hit the same error: billing for plant 1720 fails with an account determination message. Two have already created separate defects. What should Priya do?
- Create defects from the failed action or run so they link to the test case and run.
- Assign an existing open defect instead of creating duplicates; open defects carry over to new runs.
- Defect statuses are simple (New, In Progress, Retest Required, Postponed, Closed); use tags for sub-statuses.
- Bring your own severity model and keep the Responsible field current.
Check your understanding · not graded
Lesson check
1. Where are defects for manual tests created so they link automatically?
2. The same failure appears in a second run. What should the tester do?
3. Who receives notifications about a defect?
4. What can teams use to simulate sub-statuses for defects?