In
TestProcess, you will inevitably encounter developers who do not want to modify individual bugs for some reason. How do we go about developing and modifying bugs when it comes to this kind of problem?
let's start by analyzing what causes the bug to be developed without modification.1, develop and test the definition of the bug to understand the problem of inconsistency, such as violence, irregular operation problems, problem path depth, the data returned by the server is not standardized, the problem of competing products, the problem of individual models, the development may be reluctant to modify. 2.
workProcess reasons, such as the development of higher priority tasks do not have time to modify, online time urgent, too late to modify, the development of the bug under the name, Development believes that the current implementation than the product requirements of the situation 3, of course, there are individual ability reasons, such as not find a good solution, the scope of the impact, not found the cause , there is no solution, the technology is difficult to achieve, do not know how to modify and so on 4, there are also some objective factors of force majeure, such as system problems, third-party application problems and so on
my point of viewThere are so many reasons to develop a bug that does not modify bugs, but there is only one reason why we test to drive development bug fixes-that's responsibility. Xiaoguanzi less selling, countermeasures to help you through a case analysis solution ~
Ming Li also ~Xiao Ming Test input method found that after the replacement of the skin, in a goose application to adjust the keyboard and turn the screen, the keyboard will show abnormal, not normal use. After the submission of the bug, the development of research reasons, found that the input method and there is no special treatment for the turn screen, speculation may be a goose application problems, if we do adaptation changes will be relatively large. And this user is not easy to meet, and the software is on the way, so I do not want to modify. Test that the screen is a common operation, the user one but trigger this bug, the input rules are not working properly, greatly affect the user's experience. In the persistence of the test, the developer has done some protection for the input method and feedback the problem to the application, and the application owner promised to fix it in the next version. The problem was quickly resolved. Analysis of the above cases, the development of non-modification of the bug for four reasons: the bug path is deep, on-line time emergency, change the scope of impact, third-party application problems. We analyze the solution 1, for the deep path of the bug, the test in the promotion of development to fix the bug, you need to pay attention to the following points a) from the user's point of view to analyze the severity of the problem, analyze the user's probability of encountering this problem, guide the development station in the user's perspective to think, so that development awareness of the Can and developers to enumerate a similar problem before, for development to provide reference C) the product is responsible for the software personnel, when the test and development advice can not be agreed, do not because can not promote the development of changes and give up, be sure to find product confirmation, the final decision to the product personnel. 2, on-line time tense, development too late to modify, this time the test should analyze the severity of the problem, and product personnel to discuss whether the need to modify 3, modify the bug, the impact of a wide range, there is no optimal solution, etc. in the project will be on-line node comparison taboo such things happen. In the face of this situation, it is recommended that the developer do research work, consult other colleagues, or organize a temporary meeting, set the power of the people to study a good solution 4, third-party application problems, development can not be modified. After confirming the reason need to find the relevant staff, such as products, contact the third-party input method staff, feedback problems, try to push the application to solve the problem
SummaryIn short, the bug repair, testing should have a principle of their own, but also to weigh the pros and cons. Can not be pushed to develop, give up, by the bug on-line, can not pull a small bug, the impact on-line time. Tips to drive developers to fix bugs, do you get them?
Development does not change the bug? I'll give you a trick.
