Lesson 4 of 6
Writing a defect
9 min
A defect report has one job: let someone who was not there reproduce the problem, understand its impact and fix it. A good one gets fixed in a day. A vague one bounces between tester, consultant and developer for a week. The format below works for any tool, including the defect function in SAP Cloud ALM, where a defect can be created directly from a failed test run.
| Field | What to write | Contoso example |
|---|---|---|
| Summary | One line: what is wrong, where, in what condition | Sales order price for CMC-ALT-100 is 165.00 instead of 150.00 for Great Lakes Fleet Services |
| Environment | System, client, build, user and role | QAS client 100, build 14, user MARIA_T with order-to-cash roles |
| Steps to reproduce | Numbered steps from a clear starting point | 1. Open Manage Sales Orders. 2. Create standard order, sales area 1710 / 10 / 00… |
| Test data | Customer, product, plant, quantities, dates | Customer Great Lakes Fleet Services, 50 pieces CMC-ALT-100, plant 1710 |
| Expected result | From the test case, with its source | Price 150.00 USD per piece per the current price list condition |
| Actual result | Facts: values, messages with numbers, document numbers | Order 1000462 shows 165.00 USD; pricing analysis shows an old condition record |
| Evidence | Attached screenshots and document numbers | Pricing analysis screenshot; order 1000462 |
| Impact | Who is affected, how often, workaround | Every fleet order is overpriced by 10%; manual override possible but error-prone |
The fields of a reproducible defect report.
Severity is not priority
Two ratings travel with every defect and are often confused. Severity describes impact: how badly the defect damages the business process or the system. Priority describes urgency: how soon the business needs it fixed, given deadlines and workarounds. Testers usually propose severity; the test lead, with the process owner, decides priority. Most projects define three or four levels for each; use your project's definitions, not your own.
- Did the step run and produce a result different from the expected one?Yes → continue · No, it could not run → mark blocked and log the obstacle (data, role, missing transport) with the test lead
- Is the expected result itself correct and current?Yes → continue · No or unsure → flag a test-case issue and ask the process owner
- Does the problem reproduce from a clean start with the documented data?Yes → continue · No → note it as an observation, try again, and add what differed
- Is there already a defect for this problem?Yes → add your case and evidence to it · No → raise a new system defect
Writing tips that save days
- One defect per report. Two problems in one report get half-fixed and closed.
- Write the steps from a clean starting point, not "same as before".
- Quote messages exactly, with type and number; add the long text for errors.
- Say what you expected and where that expectation comes from: the test case, a specification, the process owner.
- Describe facts, not causes. "Price is 165.00" is a fact; "the pricing procedure is broken" is a guess that may send the fixer the wrong way.
- Search for an existing defect first; if one exists, add your case to it rather than raising a duplicate.
What would you do?
A tester at Contoso finds that the delivery for an order cannot be created because stock is missing in storage location 171A, although the test plan said stock would be prepared. How should this be logged?
- A defect must let a stranger reproduce, understand and fix the problem.
- Include summary, environment, steps, data, expected with source, actual, evidence and impact.
- Severity is impact; priority is urgency; the test lead and process owner set priority.
- One defect per report; facts, not guesses about the cause.
Check your understanding · not graded
Lesson check
1. Which describes severity?
2. Which summary line is best?
3. Why write "actual: 165.00" rather than "pricing procedure is wrong"?
4. You find two unrelated problems in one test. How many defects do you raise?