Development does not change the bug? I'll give you a trick.

Development does not change bugs. I'll give you a recruit. 2015-09-14 09:27 Edit: suiling Category: Program Life Source: Sogou Test 0 2497

Programmer Bug Development Recruitment information: iOS mobile phone software Development Engineer Senior iOS development engineer iOS Dev Engineer, iOS senior engineer Java Senior Software engineer iOS software Engineer Web backend Senior Development Engineer MAC Development engineer iOS technology expert advanced PHP development Engineer IO S engineer

During testing, you will inevitably encounter situations where developers 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 modifying it

1, the development and testing of the definition of the bug to understand the problem of inconsistency, such as violent operation, irregular operation problems, problem path, the server returned the data is not standardized, competing with the same problems, individual model problems, development may not be willing to modify.

2, workflow aspects of the reasons, such as the development of a higher priority of the task does not have time to modify, online time is urgent, too late to modify, development does not pay attention to the name of the bug, the development of the current realization than product demand is good and so on

3, of course, there are individual capacity reasons, such as not finding a good solution, the scope of the impact of a large, can not find the cause of the bug, there is no solution, technical implementation is difficult, do not know how to modify and so on reasons

4. There are also some objective factors of force majeure, such as system problem, third party application problem and so on.

My point of view

There are so many reasons to develop not to modify bugs, but there is only one reason we are testing to drive the development of bug fixes-that's responsibility. Do not sell less, the countermeasures to take to help you through a case analysis solution ~

Ming Li also ~

Xiaoming Test Input method found that after the replacement of the skin, in a goose application to adjust the keyboard and turn screen, the keyboard will show abnormal, can not be used normally.

After submitting the bug, the development investigates the reason, discovered that the input method has no special treatment for the turn screen, the guessing may be the question which the goose applies, if we make the adaptation change to be quite big. And this operation user is not easy to encounter, and the software on-line is imminent, therefore does not want to revise. Test that the switch is a common operation, the user once triggered this bug, the input rule is not normal use, very affect the user experience. At the insistence of the test, the developer did some protection for the input method and fed the problem back to the application, and the application manager promised to fix it in the next version. The problem was quickly resolved.

Analysis of the above cases, there are four reasons for not modifying the bug: The bug path is deep, the on-line time is urgent, the change influence scope is big, the third party application problem. We analyze the solution

1, for the path of a deeper bug, testing in promoting the development of repair bugs, you need to pay attention to the following points

A to analyze the severity of the problem from the user's point of view, analyze the user's probability of encountering this problem, and guide the development station to think from the user's point of view, so that development can realize the seriousness of the problem.

B. A similar problem can be identified with the developer, providing a reference for development

c The product is responsible for this software personnel, when the test and development views can not be agreed, do not because can not promote the development of the modification and give up, we must find product confirmation, the final decision to the product personnel.

2, the on-line time is tense, the development is too late to revise, this time the test should analyze the seriousness of the problem, and the product personnel discuss whether need to revise

3, modified bug changes are larger, the scope of the impact of a wide range, there is no optimal solution in the project will be on-line node more taboo such things happen. In this case, developers are advised to do research, consult with other colleagues, or organize an ad hoc meeting to set up a team of people to study the changes.

4, third party application problems, development can not be modified. Identify the reason after the need to find relevant staff, such as products, contact the Third-party input method of staff, feedback questions, as far as possible to promote the application to solve the problem

Summary

In short, the bug repair, testing should have a principle of their own, but also weigh the pros and cons. Can not because of push development, give up, by the bug on the line, also can not hold a small bug do not put, affect the online time. Driving developers to fix bugs requires skill, do you get it.