Contingency cannot reproduce bug how to deal with?

First, be sure to submit!!

1. Remember that there is such a flaw, you may encounter later when you will understand the cause of the occurrence.

2. Try to find out the cause of the error, such as any special operation, or some operating environment.

3. Programmers are more familiar with the program than testers, perhaps you have submitted, even if not re-, the programmer will understand the problem.

4. Once again the problem cannot be reproduced, you can call the programmer to see the problem directly.

5. For testers, there is no operation error this one. Now that it's a problem. Even if the operation is wrong, it should be pushed to the programmer, since the testers make mistakes, the user may also make the same mistake. When the error occurs, the tester is the largest.

Second, the program is not written by testers, the problem is not the cause of the testers.

As for the inability to reproduce, there are many possible reasons, because the testers see only the outside of the program, unable to drill inside the program, so it is wrong to push the responsibility to the testers.

The tester's task is to reproduce the problem, not the need to reproduce it!!

Third, the next time you meet, pull them to see it.

The programmer does not have a good solution because the problem cannot be reproduced in any way.

And even if the programmer says it's changed, the tester has no good way to verify it. : )

Four, you can tell the programmer, the test process is not wrong.

Testers only check for possible problems in the program, although testers use some means to try to cover all situations, but these are theoretical speculations. In practice, may be due to personnel, environment, configuration and other causes of various problems, in the tester found the problem is the company's internal affairs, the program sent outside can be the image of the company.

Programmers need to understand that testers are helping them, not harming them.

Customers find problems more serious than testers find.

Five, the test department is independent and Development Department of Ah, really deal with, is also manager to manager.

Here at work, the things above, and programmers can only be negotiated with each other, and no one who is high or low.

Problems can not be reproduced, but also to suggest that the programmer could not reproduce the reply. The problem is there, and when it comes up again, call the programmer to come and see it right away.

Really did not reappear, the final can be written in the report, said what happened, but can not reproduce (more serious problems to deal with this, the small problem managers to discuss the possibility of it).

As far as testers have to reproduce the bug, you kill me okay, every time I test the project there is a problem that can not be reproduced, a lot of I could find the reason, some simply can not reproduce (only once).

Such things can not be avoided, and can not say that testers can not reproduce the problem, that is, the work is not in place (hum, the program has a bug, whether it can be said that the programmer does not work in place).

Six, the testing department should be independent, preferably not under the constraints of development. In fact, if we really want to pay attention, we should have the right to veto.

Our company is the project contract, to take the final project end, it is necessary to test the department signed through, so as to avoid a lot of problems.

In fact, as long as their own heart can be, tube others how to say it.

Vii. the states we use are:

The state of the programmer's processing (action submitted by the tester): Waiting to be processed and appearing again.

Status of the tester (action submitted by the programmer): modified, temporarily unmodified, system-restricted, incorrect, non-reproducible. The tester can modify the record.

Status of the manager (the action is submitted by the tester): handled by the administrator. Managers can also delete records.

According to the comparison standard, in fact, there should be "waiting for confirmation", "confirmed" and "repeat submitted" status, we use the "waiting for the convenience of".

At the end of the term, the state of the defect is two for us, "closed" (confirmed by the tester or manager) and "temporarily unmodified" (for example, next version processing).

Hehe, the state is many, some cumbersome, especially the programmer a lot of time are not clear should reply to what state, but I personally feel for testers, these states are relatively clear, easy to handle.

八、一个 called Doer_ljy (Can fight) the Netizen replied to some content, I personally think not very appropriate, on the reply to some content, green color is doer_ljy (can fight) content:

About "can't reproduce" I think there is such a problem.

First, if you have a rigorous test plan before testing, it can be difficult to "not reproduce" the phenomenon. "Unable to reproduce" means that you do not know how to do this before you can see the bug again. Then the bug is mostly "unplanned".

I'm not sure if you're a tester. The term "unplanned" should not exist for testers. The granularity of test cases has always been a problem in the discussion, it is difficult for testers to have time and effort to write all the test cases including content, data, steps, etc. all operations (in plain words, as long as a long-handed literate people, according to the test to do, you can find all the problems, hehe, a software blue-collar feeling). Even if there really is, the meaning is not big, testing a lot of time, is divergent thinking, with a bit of creativity, want to consider in advance completely, difficult. So more time, is in the test process of use cases and so on gradually perfect, so say "unplanned" best not to mention.

Say I now test a project, there is a business, first query out the staff, there is a "Select All" button, "Select All", and then use the mouse to cancel the selection, the time for business processing, will prompt "No choice of personnel", so far all normal, but this time again to select personnel for business processing , you will still be prompted with "no selection", which is a flaw. This question I think most people will not be considered in the test case, because the conditions are very harsh: do not use the "Select All" button will not happen; Click the "Deselect All" button to do business will not happen, after all the election, the first click on personnel to transact business will not happen.

Second, the mature tester can not reproduce the bug in time, but also accurately describe the operation method of several steps before the bug occurred, test case situation. These are important for developers to analyze the cause of the bug. The so-called bug discovery Environment.

Oh, it seems I am not a mature tester. Manual testing, relatively skilled, and typing can be said to be almost, should go to where, the heart is a few, but let me completely from beginning to end of the repetition, not easy ah. When you write a test defect report, it is just a description of the procedure and what happens. Actually cannot reproduce the question, since said "cannot reproduce", namely the tester has carried on many times the verification to this phenomenon, generally from outside the program, the tester's operation is more skillful than the programmer.

Finally, I do not agree with the tester to push the "problem" directly to the coder. After all, it is everyone's cooperation, the goal is consistent. Testers are always on the first site of a bug, and should help analyze the cause of the problem. Confirm is not your own at this time miss.

Testers submit any issue, will be repeated verification, if easy to reproduce, has been proposed. Definitely not to shirk responsibility, or that sentence, to the structure of the program, do people of course than do not do the people to be clear. In addition, unless the programmer asks, I will not give the programmer to make changes to the analysis and suggestions!! The task of the tester is to find the problem and solve the problem is the programmer's thing. Doing so may affect the way programmers think about problems, and testers do more, and programmers are not grateful, but they may resent it (as if the programmer had a good impression of the testers).

Say two more questions that I've had in two days. The first one is that our program has a function of locking data. After locking, in other business, this data will no longer be used. I found that this function was not valid, and after a few times the verification is not possible, I certainly put forward. But the programmer said that this function is so, when I re-verify, there is no problem, the problem can be reproduced at that time (but I do not have a problem to pull the programmer to see it), but then there is no, can only be put there, and finally shut down. The second is in an interface, input has order requirements, you must first select a ListBox (required) and then edit the input, but one operation I did not choose the listbox on the input edit, also normal saved. Later, no matter how I did this problem did not appear (not mature AH), I gave up, and did not submit records (in order to avoid trouble).

Testers are limited in time, with little progress, and generally have no time to write even use cases, and spend a lot of time verifying the "can't reproduce" problem? Anyway, 10 minutes if the test doesn't come out, I'll give up. Serious on the submission, does not affect the When do not know.

Here are some other people's views:

Doublefalse (scattered in the arms): If you can not reproduce the bug is really troublesome, but it is best to pay attention to the test process clean environment, the correct operation, the same data source, as long as there is really a problem, will be able to reproduce. Oh, try more!!! We used to have customers to reflect the data often have irrelevant data, but in the home Test no problem, later discovered is Chinese character coding dislocation, so the same word, dislocation after it becomes another thing.

Liuxiaoyuzhou (eyesight): I've had the same problem! The main thing is to remember the circumstances of the bug! This is the key to the test! In our here can not from the current bug, is the tester's work is not in place! We have a strong programmer who speaks more than testers!

Ericzhangali (another space): first of all must commit the bug, and then do not attempt to Rd must solve this bug, sometimes you have to close this bug. If Rd thinks it is a test error, (do not understand what is called a test error, is not to say that he from the test to tell you never how to do, or the consequences of the ego ah,) that there is no way, if the communication can not solve, love think of it.

Darkcat_c (Wrong again): no bug is not reproducible, the bug is built on the standard procedures of the exception, if you follow the test case step is not likely to appear such a bug. As a tester must have a good memory ability, once there are some do not know how to produce a bug, at least you have to know that you have been roughly the operation. Good analytical skills, although you are only testing, but you should fully understand the architecture of the program, and some important internal details, otherwise you this test is unqualified. Locating bugs is a development thing, and reproducing a bug is the test's job, do not push everything to development, or you are really lower than development. (Editor's note: This kind of words, not willing to argue, the standard developer's opinion, perhaps should let them also to do the test)

liyan_1014 (goose son): I think it should be handled as follows:

1, must submit the bug, the tester responsible for the bug detailed description of the test operation steps, the symptoms of the bug occurred, and the specific circumstances of the occurrence of the bug is also described clearly, so for re-reproduction also has a certain reference.

2, testing and development between the need for good communication, if the response is an operation error, then ask the developer to explain why the operation error is allowed, in general, for error control, development over there should be a good grasp.

3, communication is the need for the way, developers of their own completion of the program has a sense of satisfaction, in general, is not allowed to destroy his feelings, if the communication as far as possible is a form of advice, let developers themselves point out their own program defects, so for developers to be acceptable.

This article transferred from: http://www.spasvo.com/news/html/20141222170051.html

Contingency cannot reproduce bug how to deal with?