Skill Hub — Testing, QA, and Delivery Validation

Defect Triage and Classification Working Skill

Produce a Defect Triage Log that assigns every found defect to a severity, priority, root cause area, and owner so the development team knows what to fix first and the project lead knows what risks remain open.

What this skill is for

Defect triage is the QA process of reviewing newly found defects, determining their impact, deciding who should fix them, and setting the order of work. It is distinct from incident triage, which is operational and reactive. Defect triage is part of the testing lifecycle: it happens after a defect is found during test execution, UAT, or regression, and before the fix is assigned to a developer. This skill ensures that defects are not merely logged but are classified with enough structure to support prioritization, trend analysis, and release decisions. The output is a Defect Triage Log that serves as the single source of truth for defect status during the test phase.

When to use this skill

Defects are being reported during test execution, UAT, or regression and the team needs to decide which to fix first.
A daily or weekly triage meeting is scheduled and the QA lead needs a structured log to drive the meeting.
The project lead needs a summary of open defect risk to decide whether the release can proceed.
Defects are being misrouted to the wrong team and rework is increasing because fixes are attempted by people without the right expertise.
Defect trends must be reported to a steering committee or quality gate review.
An audit requires evidence that defects were classified, tracked, and resolved with appropriate priority.

Real work situations

SAP pricing defect: severity vs priority confusion

A tester reports that a discount condition is not applied correctly in a sales order. The business impact is high for one customer who uses that discount, but the overall process is not blocked because standard orders still calculate correctly. The triage must classify: severity (critical for the affected customer, but the system does not crash), priority (fix before release if the customer is in the go-live scope, otherwise fix in the next wave), root cause area (pricing procedure configuration or condition record data), and owner (functional consultant or master data team). Without triage, the defect is labeled "critical" and all work stops, even though the scope of impact is narrow and the workaround is to use the old condition type temporarily.

Integration IDoc failure: routing to the wrong team

A tester reports that customer IDocs from the e-commerce platform are failing with status 51. The defect could be caused by: invalid data from the source system, incorrect mapping in the IDoc processing function, missing partner profile configuration, or a custom validation rule that is too strict. The triage must determine which layer is failing before assigning the defect. Without triage, the IDoc is sent to the ABAP developer, who fixes the mapping but misses the real cause: the source system is sending an invalid tax classification. The defect returns in production with different data.

Data migration defect: duplicate customer records

A tester reports that migrated customer records have duplicates in the target system. The triage must classify: severity (duplicates block invoicing and reporting), priority (must be fixed before go-live), root cause area (migration matching logic, source data quality, or target system deduplication rules), and owner (data migration lead or master data team). Without triage, the duplicates are fixed one by one manually, and the migration job is run again without correcting the root cause, producing more duplicates.

Inputs required

Defect reports from testers, business users, or automated tools, including description, reproduction steps, screenshots, and expected vs actual behavior.
Requirements and acceptance criteria to determine whether the reported behavior is actually a defect or a misunderstood requirement.
Test environment details: system, client, transaction, user, and data used when the defect was found.
Business process map and go-live scope to assess business impact and priority.
Team roster and ownership matrix showing which team handles which area (functional, technical, data, integration, infrastructure).
Historical defect data for trend analysis and to identify recurring issues.
Release schedule and quality gate criteria defining how many defects of each severity can be open at each gate.

Questions to ask

What is the exact symptom, and can it be reproduced consistently?
Which requirement or acceptance criterion is violated, and is the report actually a defect or a change request?
How many users, transactions, or records are affected?
Is there a workaround, and how much effort does it require?
Which business process is blocked or degraded, and is it in the go-live scope?
Which system layer is failing: data, configuration, code, interface, or infrastructure?
Which team has the expertise and access to fix this layer?
Has this defect or a similar symptom appeared before?

Working method

Gather defect reports. Collect all new defects since the last triage. Verify that each report includes: reporter, date, system, transaction, steps, expected behavior, actual behavior, and evidence (screenshot, log, IDoc number).
Reproduce the defect. Before classification, attempt to reproduce the defect in the test environment. If it cannot be reproduced, request more information or close it as "cannot reproduce." Do not classify unreproduced defects.
Determine if it is a defect or a change request. Compare the actual behavior to the approved requirement and acceptance criteria. If the behavior matches the requirement but the user wants it changed, convert the item to a change request and route it to the backlog. Do not treat change requests as defects in the triage log.
Classify severity. Use a four-level scale: Critical (system crash, data corruption, complete process block), Major (significant functional error with workaround), Minor (cosmetic, spelling, non-standard behavior with no business impact), Trivial (typos, alignment). Record the severity in the log.
Classify priority. Use a three-level scale: High (fix before next test cycle or release), Medium (fix before go-live), Low (fix in next release or maintenance window). Priority is driven by business impact, go-live scope, and workaround availability, not by severity alone.
Identify root cause area. Classify the defect into one of: data quality, configuration, custom code, standard code, interface, infrastructure, user error, or requirement gap. This classification drives trend analysis and prevents misrouting.
Assign owner. Map the root cause area to the team roster. Assign the defect to a named individual or team, not to a generic queue. Include a due date based on priority.
Record in the Defect Triage Log. Use the template below. Include defect ID, summary, severity, priority, root cause area, owner, due date, and status.
Run the triage meeting. Review the log with the project lead, QA lead, and team leads. Resolve disputes about severity or priority. Escalate disagreements to the steering committee if needed.
Track to closure. Update the log daily. Verify that fixes are retested before closure. Do not close defects without retest evidence.

Decision rules

If a defect cannot be reproduced, do not classify it. Request more information or close it as "cannot reproduce."
If a defect is actually a change request, remove it from the triage log and create a backlog item with the original report attached.
If a defect affects a business process in the go-live scope, priority is at least Medium regardless of severity.
If a defect has no workaround and blocks testing, priority is High regardless of the number of affected users.
If a defect is assigned to a team that does not own the root cause area, reassign it immediately. Do not let misrouted defects age.
If a defect recurs after a fix, escalate severity by one level and require root cause analysis before the next fix attempt.
If the number of open Critical defects exceeds the quality gate threshold, halt the release until the count is below the threshold.

Deliverables

Defect Triage Log — Per test cycle or per release. Contains defect ID, summary, severity, priority, root cause area, owner, due date, and status. See template below.
Triage Meeting Minutes — Record of decisions made, disputes resolved, and escalations initiated.
Defect Trend Report — Count of defects by severity, priority, and root cause area over time, showing whether quality is improving or degrading.

Templates

Defect Triage Log (compact)

---
artifact: Defect Triage Log
cycle: <Test cycle name>
release: <Release version>
status: open | closed
---

| ID | Summary | Severity | Priority | Root Cause Area | Owner | Due Date | Status |
|----|---------|----------|----------|-----------------|-------|----------|--------|
| DEF-001 | Discount not applied in sales order | Major | High | Configuration | Functional Consultant A | 2026-06-14 | Open |
| DEF-002 | IDoc status 51 on customer create | Critical | High | Interface | Integration Developer B | 2026-06-13 | Open |
| DEF-003 | Duplicate customer after migration | Critical | High | Data Quality | Migration Lead C | 2026-06-14 | Open |
| DEF-004 | Label misspelling on invoice form | Trivial | Low | Custom Code | ABAP Developer D | 2026-06-20 | Open |
| DEF-005 | Report variant missing new filter | Minor | Medium | Custom Code | ABAP Developer D | 2026-06-16 | Open |

## Trend summary
- Critical: 2 open | Major: 1 open | Minor: 1 open | Trivial: 1 open
- Data Quality: 1 | Configuration: 1 | Interface: 1 | Custom Code: 2
- Total open: 5 | Total closed this cycle: 12

Quality checklist

Every defect in the log has been reproduced before classification.
Every defect is classified as either a defect or a change request, with no ambiguity.
Every defect has a severity, priority, root cause area, and owner.
Severity and priority are independent: a high-severity defect can be low priority if a workaround exists and it is out of scope.
Owners are named individuals or teams, not generic queues.
Due dates are realistic and based on priority and release schedule.
The trend summary shows counts by severity and root cause area.
Open Critical defects are below the quality gate threshold.
All closures are supported by retest evidence.

Common mistakes

Treating every reported issue as a defect. Consequence: the triage log is polluted with change requests and requirements questions, making trend analysis meaningless and diluting developer attention.
Conflating severity and priority. Consequence: all defects are labeled critical and the team cannot prioritize. A crash in a report used monthly is not the same priority as a missing discount for the top customer.
Assigning defects to generic queues. Consequence: defects sit unassigned, age past the due date, and are discovered late in the release cycle when they are harder to fix.
Skipping reproduction before classification. Consequence: defects are classified, assigned, and fixed based on a misunderstanding. The fix does not address the real problem, and the defect returns.
Closing defects without retest evidence. Consequence: the defect is assumed fixed but still exists. It is found again in UAT or production, causing rework and trust erosion.

Weak output vs Strong output

Weak output

A plain list of defects with no classification: "Bug 1: discount is wrong. Bug 2: IDoc fails. Bug 3: duplicate customer. Bug 4: label typo. All need to be fixed ASAP." No severity levels, no priority, no root cause area, no owner, no due dates, no reproduction status, no trend summary.

Why it fails: Developers do not know what to fix first. The project lead cannot assess release risk. The QA team cannot show improvement trends. Defects are fixed in random order, and critical items may be delayed while trivial items are addressed first.

Strong output

---
artifact: Defect Triage Log
cycle: UAT Wave 2
release: S/4 2026.06
status: open
---

| ID | Summary | Severity | Priority | Root Cause Area | Owner | Due Date | Status |
|----|---------|----------|----------|-----------------|-------|----------|--------|
| DEF-002 | IDoc status 51 on customer create | Critical | High | Interface | Integration Developer B | 2026-06-13 | Open |
| DEF-003 | Duplicate customer after migration | Critical | High | Data Quality | Migration Lead C | 2026-06-14 | Open |
| DEF-001 | Discount not applied in sales order | Major | High | Configuration | Functional Consultant A | 2026-06-14 | Open |
| DEF-005 | Report variant missing new filter | Minor | Medium | Custom Code | ABAP Developer D | 2026-06-16 | Open |
| DEF-004 | Label misspelling on invoice form | Trivial | Low | Custom Code | ABAP Developer D | 2026-06-20 | Open |

## Trend summary
- Critical: 2 open | Major: 1 open | Minor: 1 open | Trivial: 1 open
- Data Quality: 1 | Configuration: 1 | Interface: 1 | Custom Code: 2
- Total open: 5 | Closed this cycle: 12
- Quality gate: max 0 Critical open at go-live. Action: resolve DEF-002 and DEF-003 by 2026-06-14.

Agent instructions

AI Prompt Pattern

Role: QA defect triage lead for an enterprise SAP project.

Context: You have defect reports from testers, requirements, and a team roster. You need to produce a Defect Triage Log that classifies each defect so the project can prioritize fixes and assess release risk.

Task: Reproduce, classify severity and priority, determine root cause area, assign a named owner, set a due date, and produce a trend summary.

Output format: Defect Triage Log in Markdown table format, plus a trend summary section.

Never classify a defect that has not been reproduced. Request more information or close it as "cannot reproduce."
Always separate defects from change requests. If the behavior matches the approved requirement, convert the item to a change request and remove it from the triage log.
Always classify severity and priority independently. Severity is technical impact. Priority is business urgency. Do not default both to the same level.
Always assign a named owner or team. Generic queues are not acceptable. If ownership is unclear, produce an ownership matrix before assigning.
Do not close defects without retest evidence. A fix is not complete until the original tester or a QA analyst has verified it in the test environment.
Do not invent defect reports, requirements, or team rosters. Use the inputs provided. If inputs are missing, flag the gap.
Link to Atlas diagnostics when defects touch SAP processes. For example, IDoc failures should reference SAP IDoc Status Diagnostics to help classify root cause area accurately.

Related skills

Test Case Design — Provides the cases that defects are found against.
QA Review and Sign-Off — Uses the triage log to assess release readiness.
Test Evidence Review — Verifies that defects are properly documented with evidence.
Incident Triage — Distinct operational triage for production incidents, not QA defects.

Related Atlas pages

SAP IDoc Status Diagnostics — Reference for classifying interface-related defects and root cause areas.
SAP Credit Management Diagnostics — Context for defects in pricing and credit blocking.
SAP Master Data Duplicate Diagnostics — Reference for data quality and migration-related defect classification.

Verification status and limitations

This skill is a public working interpretation of QA defect triage practices. It is not official ISTQB, ITIL, or SAP documentation. It focuses on structured classification within the testing lifecycle, not on production incident management or DevOps error tracking.

Known limitations: the skill assumes a defect reporting process exists and that testers can provide reproduction steps. It does not cover automated defect classification using AI or log parsing. It does not address security vulnerability classification (CVSS), which requires specialized scoring. Severity and priority scales are suggestions; organizations with established scales should use their own definitions.