Why did developers refuse to modify my defects?

Defect Is An important output of testers during the testing process. It is not only a bridge to communicate with other project stakeholders, but also an important means to prove the testing capability of testers. However, in actual testing, defects submitted by testers are often rejected by developers for various reasons.

Is
To reduce the number of defects rejected by software developers, we first need to understand why developers reject the defects submitted by testers, or why they are unwilling to spend time and energy solving the problems raised by testers.
Defects. This article will analyze the reasons for rejection of defects from several different perspectives, so as to put forward some targeted suggestions to help testers Minimize the number of defects rejected by developers. According to the author's story
The reasons why developers refuse to study and modify defects are as follows:

°


Developers cannot reproduce defects (rather than reproduce defects );

°


The information provided in the defect report is insufficient, or it may take a strange and complex step (hard to understand) to reproduce the defect );

°


Developers think it is a functional point of the system, while testers think it is a defect (defect or functional point );

°


Developers do not understand the roles and responsibilities of testers (the roles of testers );

1
) Defects cannot be reproduced.

The first possible reason developers refuse to study and fix bugs submitted by testers is: I cannot reproduce these bugs, or they are not found in my environment.

In
During testing, testers often encounter problems that cannot be reproduced or are difficult to reproduce, especially during non-functional testing, such: stability testing, stress testing, full configuration testing, and compatibility testing
. Generally, these problems are difficult to reproduce, and the results are generally serious, such as unstable system performance and random system restart. At the same time, these problems are often the most important issues for users.
If such a serious problem occurs during use, the user's confidence in the product will be greatly reduced.

Even if the problem is hard to reproduce, it is recommended that the tester submit the defect report. However, before submitting a defect report, testers should adopt appropriate policies and suggestions to provide appropriate information for developers to locate and fix such problems as soon as possible to help them solve the problem as soon as possible. My suggestions include:

°


First, the tester develops the habit of opening the system debugging window (if provided by the system) and recording the printed information of the system during the testing process from time to time. When detecting abnormal system performance, the tester can capture the abnormal system print information, which helps the developer track and locate the cause of the defect, this helps developers solve such defects;

°


Its
When the tester encounters abnormal system performance, he can first determine whether the problem may be difficult to reproduce. If it is hard to reproduce, the tester can first retain the current test environment and ask the developer to come to the site
Locate and analyze the possible causes. If developers can analyze the possible causes from the current environment, it is much easier for testers to write defect reports;

°


Third, when testers report non-reproducible defects, they should clearly inform developers of non-reproducible or non-reproducible defects in the defect report, so as to avoid limited time and resources, developers focus too much on modifying such defects;

°


Fourth, it is recommended that testers submit defects that are hard to reproduce, and continuously collect and analyze the defect databases that are hard to reproduce within the Organization. Regularly browse these defects and conduct centralized analysis. Some common or possibly related information may be found in different defect descriptions, which helps solve the problem;

2
) The defect report is hard to understand.

The second possible reason for developers to reject defects submitted by testers is that the defect report contains too much content and information, and developers do not even know what the testers want to say, it is also difficult to understand what the tester wants to explain.

Missing
Trap report is an important output of testers during the testing process. Many times, project stakeholders recognize testers through defect reports. Good defect reports can bring a good reputation to testers, while poor reports
Reporting may bring additional work to stakeholders. If a tester's defect report wastes too much time and resources from project stakeholders, they subconsciously resist and reject their defect reports.

Compiling a good defect report is a basic skill for testers. Efficient defect reporting is of great significance to testers. In addition to reducing the number of defects rejected by developers, it also helps improve the reliability of testers and the cooperation between developers and testers.

A good defect report is what the tester finds during the test, not just telling the developer what we did. This is important for compiling high-quality defect reports. In addition, when preparing a defect report, we should make the report as characteristic as possible:

°


Concise: The description of the defect should be clear and concise. Remove unnecessary languages from the defect report. Second, do not add irrelevant information. The defect report contains all information related to the defect and is indeed relevant. The redundant information will only increase the ambiguity of the defect description;

°


Correct: The submitted question is indeed a defect. If the final proof of the submitted defect is due to an incorrect understanding or configuration error, the tester will lose credibility in front of the developer and will have some impact on communication between the testers;

°


Isolation: Try to find a short step to reproduce the defect and isolate the defect. For example, which module has a problem? Which input condition triggers this defect? Which action causes the failure. The ability to isolate and locate problems can greatly increase the testing staff's testing efficiency and the overall project efficiency;

°


Promotion: Determine whether other parts of the system may have the same problem, and whether the problem may occur when different data is used. The ability of testers to promote defects can help reduce the time required for developers to modify defects and improve the efficiency of defect resolution;

°


Replay
Now: Determine whether the system can reproduce the problem and what type of step input is required to reproduce the problem. Simple Steps and inputs are provided for problems that can be reproduced. To solve problems that are hard to reproduce, try to provide
When alarm information and log information are sent to developers, or when problems are detected, you can perform tracking, debugging, and locating with developers. For problems that cannot be reproduced, it is clearly stated in the defect report and will be tested later.
Pay attention to tracking;

°


Evidence: Just as writing test cases requires test conditions, in the defect report, the tester needs to provide the expected and actual results of the test. What is the reference document ?;

In addition to the above requirements, after preparing the defect report, the tester can request experienced testers or test managers to read the report before submitting the report. This helps improve the quality of defect reports.

3
) Defects or functions

The third possible reason for developers to reject defects submitted by testers is that they think this is a normal feature (or feature point), and testers think this is a problem.

The main reason for the divergence between developers and testers on the same performance behavior of the system may be their input to the system, for example, the requirement document. By reasonably defining the roles and responsibilities of system personnel, developers and testers, this problem can be better solved. The relationship between the three elements is as follows:

 

Figure
1
R & D personnel relationship

Figure
1
Description
System personnel are the foundation and core of software development and software testing. The system personnel can convert the user requirements of the product into detailed requirement specifications. Software personnel use this as the basis after Requirement Specification baseline
The system overview design and detailed design are carried out, while the tester designs the software testing strategy and detailed test cases according to the Requirement Specification Description. At the same time, both software personnel and Software testers need to work closely with system personnel
Feedback the development activities and test activities of various stages to the system personnel to improve and optimize the system requirement specifications. According to the definition of such roles and responsibilities, if developers and testers
When there are differences between the table actions of a product, the system staff can make the final decision. Through software development process control and management, developers and testers can better avoid entanglement.
It is a feature. "This type of problem can improve our testing efficiency and facilitate communication between project stakeholders.

4
) Tester role

The fourth possible reason for developers to reject defects submitted by testers is that the product requirement specification does not have such requirements, and the features and features in the requirement specification have been implemented.

Introduction
The main reason for this problem is that developers are unclear about the roles and responsibilities of testers. If developers do not have a good understanding of the work of testers, then there are defects between developers and testers.
Communication will also have some problems. So what are the roles and responsibilities of testers? We believe that testing should run throughout the entire software development lifecycle, not just after the code stage.
Activity. Introduced here
Verification
And
Validation
Two concepts:

°


Verify (
Verification
)
: Checks and provides objective evidence to determine whether the specified requirement is met. That is, the comparison between input and output. That is to say, it is to check whether the software has correctly implemented the system functions and features defined by the product specification, that is,"
Are you building the product right
".

°


Confirm (


Validation


)


: Check and provide objective evidence to verify whether a specific function or application has been implemented. During validation, the scope of use and application conditions should be considered to be far greater than the range determined at input. Generally, it is executed by the customer or the person representing the customer. That is to say, it is an activity to confirm whether the developed software meets the real needs of users, that is,"


Are you building the right product


".

According


Verification


And


Validation


Two
Concept, we can see that in addition to verifying whether the product meets the requirement specification, the tester also needs to analyze whether the product is really what the customer requires from the customer's perspective. Therefore
In addition to reporting functional defects, testers need to pay special attention to some non-functional features, especially the requirements that may not be clearly defined in the requirement specifications that users are concerned about. For example: is the product easy to use?
Whether the graphic interface layout is reasonable or not.

Previously, we talked about how developers refuse to fix defects submitted by testers.


4


Items
The main reasons are as well as some suggestions based on the author's experience. Of course, we will certainly encounter some other reasons during the testing process, resulting in developers not willing to fix some defects. For whatever reason
We need our testers to have good communication skills, standardized and rigorous defect report writing skills, and good cooperation to help developers better understand the test work, in this way, defects can be detected and repaired better and faster,
Timely release of high-quality products.

 

References:

[1]


Zheng Wenqiang, Ma junfei, Software Test Management, Electronic Industry Press,


2010-7

[2] Cem Kaner, Etc., lessons learned in software testing, John Wiley & Sons, inc., 2001