Developers don’t fix bugs? Here’s a tip for you

[[148861]]

During the testing process, it is inevitable that developers do not want to fix individual bugs for some reasons. So when we encounter this kind of problem, how should we promote the development and fix the bug?

Let's first analyze what reasons may cause developers to not fix bugs.

1. Problems caused by inconsistent understanding of the definition of bugs between development and testing, such as problems caused by brute force operations, unconventional operations, deep problem paths, non-standard data returned by the server, problems similar to those of competing products, problems with individual models, etc. Development may be unwilling to make changes.

2. Reasons related to the workflow, such as the developer has higher priority tasks and has no time to modify, the launch time is urgent and there is no time to modify, the developer does not pay attention to the bugs under his name, the developer thinks that the current implementation is better than the product requirements, etc.

3. Of course, there are also personal reasons, such as not being able to find a good solution, a large impact range, not being able to find the cause of the bug, no solution, difficult technical implementation, not knowing how to modify, etc.

4. There are also some objective factors beyond our control, such as system problems, third-party application problems, etc.

My opinion

There are so many reasons why developers don't fix bugs, but there is only one reason why we testers push developers to fix bugs - responsibility. Let's stop keeping you in suspense and get the countermeasures - we'll help you analyze the solution through a case study.

Xiao Ming is here~

When Xiao Ming was testing the input method, he found that after changing the skin, when he called up the keyboard in a certain goose application and rotated the screen, the keyboard would display abnormally and could not be used normally.

After submitting the bug, the developer investigated the cause and found that the input method did not do any special processing for screen rotation. It was speculated that it might be a problem with a certain goose application. If we make adaptation changes, it would be relatively large. In addition, this operation is not easy for users to encounter, and the software is about to be launched, so we don’t want to modify it. The test believes that screen rotation is a common operation. Once the user triggers this bug, the input method cannot be used normally, which greatly affects the user experience. With the persistence of the test, the developer made some protection for the input method and fed back the problem to the application. The person in charge of the application promised to fix it in the next version. The problem was quickly solved.

Analyzing the above cases, there are four reasons why developers do not modify bugs: the bug path is deep, the launch time is urgent, the change affects a large range, and there are problems with third-party applications. We analyze the solutions one by one

1. For bugs with deeper paths, the following points should be noted when testing to promote development and fix bugs

a) Analyze the severity of the problem from the user's perspective, analyze the probability of users encountering this problem, and guide developers to think from the user's perspective, so that developers can realize the severity of the problem

b) You can list a previous similar problem with the developer to provide a reference for development

c) Product managers are responsible for the software. When testing and development cannot reach an agreement, do not give up just because you cannot push for development modifications. You must find product managers for confirmation and give the final decision to product managers.

2. The launch time is tight and the developer has no time to make changes. At this time, the tester should analyze the severity of the problem and discuss with the product staff whether it needs to be modified.

3. Bug fixes are relatively large, have a wide impact, and there is no optimal solution. This is a taboo when the project is about to go online. In this case, it is recommended that developers do research, consult other colleagues, or organize an ad hoc meeting to gather everyone's strength to study a good modification plan.

4. Third-party application problems cannot be modified by developers. After confirming the cause, you need to find relevant staff, such as product staff, contact the staff of the third-party input method, report the problem, and try to promote the application to solve the problem.

summary

In short, whether to fix bugs or not, testers should have their own principles, and they should also weigh the pros and cons. You can't give up and let the bug go online just because you can't push the development, nor can you hold on to a small bug and affect the online time. It takes skills to push developers to fix bugs. Do you get it?