What if the bugs found can't be reproduced? _ Software Testing theory

Twitter throws a discussion topic: In the afternoon, a test lead asks that some bugs will appear in a version, and then record it, but developers reject it when the current B version attempts to reproduce. Then the test is depressed, until the next round of regression test may be the C version D version, if the natural reopen, but if not reproduced whether it should really turn off it. How do you deal with this sometimes bug?

This problem may be met by every tester, and I'll talk about my personal opinion for you to discuss.

1. Bugs found in version A should be reproduced in a version we know that there are a number of reasons why a version of a bug may not be reproduced in version B: 1 The developer secretly solved the bug to avoid being subject to KPI evaluation; 2 environment Difference, possibly B version of the code in a version of the environment will also be problematic, However, in the development environment may not be reproduced, 3 code changes may be caused by other code BUG,B version of the other development has been modified, this can be summed up for the associated function caused by bug;4) AB Two version of the recurrence of the predecessor conditions and steps have been different.

Since there are so many possibilities, we should eliminate the impact, make the problem simple, and keep the environment and code in the same situation to reproduce. A version of the bug if the B version can not be reproduced, time and conditions allow, then back to a version of the code, there is a premise does not have to return, that is the correct positioning of the problem, and to determine in the B version has been resolved it.

2. When project time is allowed, developers should collaborate vigorously to reproduce bugs

For "difficult diseases", developers should work closely with testers to replicate: 1 if you print more log;2 for poorly debugged code, you can connect the test environment database and roll back the code to version a, and add breakpoints to debug your code according to the information you have learned. 3 to do more detailed code Review and so on. The part of the code that you are responsible for determines that there is no problem, this time need to consider the interface, whether the interface data processing problems, you need other developers to cooperate. and testers need to do their best to restore the scene at the time: environment, data, preconditions and test steps.

3. Testers have to reconfirm that the coverage and sophistication of test cases can result in a number of situations that are not reproducible: 1 environment; 2 code; 3 data.          And the data can be summed up in the code fault-tolerant processing, the environment can be very good to restore, the emergence of the bug is not easy to reproduce is attributed to the majority of the code and data on the test, the use case design coverage is not enough rigorous will lead to bugs not in our grasp. This time, we have two kinds of situations: one is the original use case has not been well designed, without review, we test is very casual, do not doubt, hurriedly put the use case to ponder, and then call on the project related personnel to review, so the purpose is to ensure that the test cases have been the project related personnel recognition, All kinds of situations have been discussed, to ensure that the needs of everyone's consistency, to ensure that the software coverage to meet the requirements of the project requirements, to achieve demand 100% coverage, developers to make more suggestions, it can also make up some black box test may be omitted Second, the project has been a rigorous needs assessment and use-case review. Of course, even so it is not possible to avoid leakage and special considerations.

Of course, the premise of this is that the bug is very serious, affecting the release of the release, it is necessary to summon people to work together to solve it.

4. Racking your brains, it still can't reproduce when keeping an eye on

I believe that through the efforts of the above steps, still can not reproduce the bug must not be high priority, then assess the importance of the project team, if the decision does not affect the release, pay close attention to the bug, after the release of the verification will also focus on the next. The bug cannot be closed, then postponed to later versions, and attempts to reproduce each round of tests. When can it be closed? Perhaps 3, 5 releases after release, no problem can be decided to close it.

5. Consider the test process and test specifications, timely correction through the detour, the formulation of the specification of the bug, easy to develop and our own reappearance once, there will be a second, we should respond promptly, even if we can not mend, but also to be anticipatory. The specification for submitting bugs, this may be different for each company, some companies have limited wood, and the bugs submitted are thousands of people, which is a challenge for developers to understand bugs and reproduce bugs. The specification of a bug submission can be useful if you record the prerequisites for this bug, the data you use, and the steps you take. Of course, this is not to say that every bug is so detailed.