How to write a good defect (Defect) Report

Writing defect reports is a daily routine for testers, and good bug reports make it easier for developers to understand and locate problems faster, and bad bug reports can mislead the investigation direction and increase communication costs. So what should a good defect report include?

Please look at my mindmap:

Title

1. First of all to do a "title Party" (this title party non-title party). The title must be clear and concise and easy to understand, should not congestion long

2. As far as possible prefix to specification, such as Template: [Product][version]_[feature]_[title], so the description will be very clear, but also easy to find

3. The title of the defect be sure to describe the circumstances under which the problem occurred

4. Try to avoid the use of personal (such as you, I, etc.)

Example of a defect title: DEMOAPP 1.0_login_cannot Enter username by Copy/paste enternal string

This title contains the product name, version number, module, what happened (cannot enter username), and under what circumstances (Copy/paste enternal string)

Description or summary

Describe or summarize this module can be used to describe the title does not fit the more detailed content, it can include many aspects, such as the relevant, historical version is reproduced, user operation and so on. The aim is to describe the defect in a clearer and more detailed.

Effect

This section describes the impact of this flaw on the user's actual application.

Front-facing conditions

Describe the environment, data, or other special needs before reproducing the defect.

Repro steps

From the user's point of view to describe the repro step, there should not be too much business jump between steps, preferably coherent.

For example:

Repro Steps:

1. Open DemoApp to enter Login screen

2. Copy username from enternal file

3. Paster username to username field of Login screen

Results

Results can be divided into "expected results" and "actual results", which can be multiple or interspersed between repro steps (such as problems with multiple defects in the repro step)

Priority level

Everything is prioritized, and defects are identified with priority and urgency, so that the development team decides to do it or postpone it.

Recurrence frequency

Of course, most of the defects can be reproduced 100%, for a few defects may be difficult to reproduce, or not easy to reproduce, it is necessary to indicate the probability of recurrence, such as 50%. Often this flaw requires detailed log files to obtain a replay from the log angle or to resolve the breach.

Attachment

Accessories are very important! Attachments can be in a variety of formats, pictures, log files, videos, and more. In addition to providing intuitive knowledge (images, videos), there can be more information (bug discussion emails, logs, etc.).

Workaround (workaround)

The workaround is to provide a way to use other product features that bypass the current problem. This allows the customer to continue using the product in the event that the defect is not resolved.

Occurrence cause analysis (Root cause analyst)

Describes how this flaw occurs from a code perspective. Testers who can do this need to have a higher ability to read and write code.

Environment configuration

A configuration that describes the test environment, such as the OS, the corresponding product version, and so on.

So, here's the problem! Defects include so many aspects, if each flaw is so written, how much effort to spend!!! (after all, the most busy test!) ）

Personally, there is no need to write every one of these, after all, writing a bug report does not have value for the customer. Defect reporting is a defective information carrier, and its existence is meant to be used for better, clearer communication between development teams and later review, to what extent or need to choose according to the actual situation. (such as root cause analysis can be ignored in the case of time is not rich, etc.)

The above-mentioned aspects, below is a template, I hope to help you.

Title: [Product][version]_[feature]_title description/summary: Impact: priority/severity:Critical Frequency:100% Precondition: Repro Steps:Step 1:step 2:expected result:actual result:step 3: expected Result: Actual Result: Root cause Analysis:   Workaround:   Environment:   attchment:

How to write a good defect (Defect) Report