[Switch] The defect description is improved in this way.

AsTestPersonnel, submitting defects is what we must do. I wonder whether each person has considered it or not. defect description is also an "art". It reflects a person's test experience and test depth. Whether the defect description can be done well directly affects our testing efficiency. More specifically, it affects the efficiency of developers to modify defects. A high-quality defect description allows developers to enjoy and improve theirWorkEfficiency. A confusing defect description not only makes development feel helpless, but also reduces the trust of testers. Therefore, a good defect description reflects the basic quality of a tester.

Silly brother's blogArticle"How to Write high-quality defect description" gives me some ideas on how to improve the description of defects. I 'd like to share it with you. The following is an example of the incorrect depreciation data in the Financial monthly report of assets.

Personnel	Defect description
Tester 1	The depreciation data of the asset financial monthly report is incorrect.
Tester 2	The sum of the depreciation data in the asset financial Monthly Report and the asset ledger details is not equal to 287.53 RMB.
Tester 3	The depreciation data of the asset financial monthly report is incorrect. The depreciation data of zc_zjjl (Asset Depreciation record) and zc_yjjl (Asset monthly close record) are different.
Tester 4	As long as the asset is reset, the sum of the depreciation data of the financial Monthly Report and the asset ledger details does not match.
Tester 5	The depreciation data of the asset financial monthly report is incorrect. After investigation, it is found that the reset amount of the asset and zc_yjjl (Asset monthly close records) is not updated at the end of the month after the asset is reset, the depreciation amount is calculated based on the amount before resetting, resulting in incorrect monthly asset data. The monthly settlement processing algorithm is incorrect. Modify the algorithm.

From the above example, we can see that there are five arguments for a defect. If you are a developer and you want to see which tester has a defect, it must be 5th bits. It not only clearly describes the existing defects of the system, but also helps developers find the root cause of the defects. You may also think that no matter what the problem is, I have already described the problem in the system, and the development will always find the cause. Next, let's take a look at it, development replies to these five defects.

Personnel	Developer reply
Tester 1	I tested it here. The depreciation data is correct, not a defect.
Tester 2	I tested it here. The depreciation data is correct, not a defect.
Tester 3	The two tables in my development library are correct. Please confirm again.
Tester 4	Dizzy, I checked it for two hours. My financial statement is correct. The algorithm for processing Michael's monthly statement is wrong. Please submit it to Michael.
Tester 5	Zhang San replied: brother worked hard and had dinner together at noon.

It may be a bit ridiculous, but I think these situations have always been met in everyone's work. For some defects that are unclear or inaccurate, they are often rejected by developers. I have summarized some of my experiences:

1. Tracing. Defects also have surface phenomena and real causes. We should not only see the surface phenomena in the system, but also identify the true causes of defects through step-by-step analysis. It is possible to discover it through multiple test cases, and sometimes it is necessary to search for it in multiple tables. As a tester, we should take a serious and responsible attitude to discover the true root cause of any small defect.

2. Comprehensive. Describe the actual situation of a defect in detail. As testers, we are much more familiar with the business than developers. Sometimes, you can simply describe the process of generating a defect, but developers do not know how to "jump. Therefore, we should make the description as detailed as possible.

Iii. Concise and concise. It may sound a little different from the second point, but this is something we should pay attention. The development cycle is quite compact. We should describe defects in the simplest language and use short sentences to ensure logical clarity.

 

Turn: http://blog.csdn.net/not_a_baby/article/details/6743300

[Switch] The defect description is improved in this way.