Lesson 3 of 5
Defect and risk views
9 min
Listen to this lesson
Coverage says what has been tested. Defects say what is still wrong. A gate needs both. In Cloud ALM, testers create defects from failed test steps in the Test Execution app, and each defect carries a priority, a responsible team or person, a due date and links back to the test run and so to the test case, requirement and process. Those links are what let you slice defects by business process instead of by whoever happened to log them.
The four defect views a gate needs
| View | Question it answers | Contoso example |
|---|---|---|
| Open defects by priority | Is anything blocking? | 0 very high, 3 high, 21 medium, 40 low |
| Open defects by process or scope | Where is the risk concentrated? | 2 of the 3 high defects are in record to report |
| Created vs resolved trend | Are we converging? | Resolved has exceeded created for two weeks |
| Defect age and status | Is anything stuck? | 6 defects in Retest Required for more than 5 days |
Defect views for a gate. Cloud ALM provides defect lists and analytics that you can filter and group this way.
Reading the trend
A count of open defects is a photograph. A trend is a film. If created and resolved lines have crossed (more resolved than created each week), the solution is stabilizing. If new defects are still arriving faster than they are fixed a week before the gate, the gate is likely to fail on defect criteria, regardless of today's count. Show the trend for the whole cycle, not just the last week.
Turning defects into risk statements
Sponsors do not decide on defect IDs; they decide on risks. For each open high-priority defect and for any cluster of medium ones, write a short risk statement: what could go wrong in production, for whom, how likely, and what the workaround is. For Contoso, a defect in revenue account determination becomes "Billing for fleet customers may post to the wrong revenue account; finance would need manual reclassification at month-end; workaround documented; fix due before UAT ends."
- FilterOpen defects for the gate scope and cycle
- GroupBy priority and by process
- Check trendCreated vs resolved across the cycle
- Find stuck itemsAge in status, especially Retest Required
- Write risk statementsImpact, likelihood, workaround, owner, due date
- SnapshotExport with filter, date and author for the gate record
Defects that live outside test runs
Not every defect comes from a failed test step. Some are raised during design reviews, data loads or cutover rehearsals, and Cloud ALM lets you create a defect without a test run. Those defects have no automatic link to a test case or requirement, so they can drop out of process-level views. Ask whoever raises them to set the scope or solution process explicitly, and include an "unlinked defects" filter in your gate preparation. At Contoso, three data migration defects about inventory in storage location 172A were found this way the week before the gate; they were not in any test run, but they were very much a go-live risk for the Chicago plant.
What would you do?
Two days before Contoso's end-of-Realize gate, the defect view shows only 3 high-priority defects open, within the threshold. But the created-versus-resolved trend shows 40 new defects last week and 22 resolved. What should Priya tell the gate?
- Defects created from failed test steps link back to test cases, requirements and processes.
- Show open defects by priority and by process, the created-versus-resolved trend, and stuck items.
- Translate high-priority defects into risk statements with workaround, owner and date.
- A closed defect needs a passing retest; check that before the gate.
Check your understanding · not graded
Lesson check
1. Where are defects usually created during manual testing in Cloud ALM?
2. What does a created-versus-resolved trend tell you that a count does not?
3. Why group open defects by process?
4. What should a gate risk statement for a defect contain?