Can an accident need to be reproduced?
In the software engineering forum, Kasad "asks if the occasion can be deducted?" I discussed some netizens. The following is some records of the finishing, mainly ME. Original post: http://community.9cbs.net/expert/topicview3.asp? Id = 3867252
First, be sure to submit! !
1.
I remember that there is such a defect, and it may be possible to understand the reason when I encounter it.
2.
Try to find the reason for the error, such as what special operation, or some operating environment, etc.
3.
Programmers are familiar with the program than the test personnel, maybe you are submitted, even if you can't re-re-need, the programmer will understand the problem.
4.
If the problem that cannot be reproduced is once again appeared, you can directly call the programmer to see the problem.
5.
For testers, there is no operation error. Since encounter, it is a problem. Even if it is really wrong, it is also necessary to push to programmers. Since the tester makes mistakes, the user may also make the same mistake. When the error occurs, Tester is the largest.
Second, the program is not written by testers, and problems are not the reasons for testers.
As for the possible reasons, there may be a lot, because the testers see is only the exterior of the program, can't go deep into the program inside, so the responsibility is pushed to the test person.
Test staff's mission is just try to reproduce problems, not to reproduce! !
Third, when you encounter it next time, you can take them.
Because the problem does not have any good solution if you can't reproduce it.
And such problems have changed even if the programmer is modified, the tester does not have a good way to verify it. :)
Fourth, you can tell the programmer, the test process is not wrong.
Test persons are only the possible problems that may exist in the program, although testers use certain means of means of work hard to override all the situation, but these are the theoretical speculation. In practice, there may be a variety of problems due to various reasons such as personnel, environment, and configuration. It is the company's internal problems in the company, and the program is the company's image problem.
It is necessary to let the programmer understand that the tester is helping them, not harming them.
The customer found that the problem was more serious than the test results.
5. The test department is an independent and development department. It is really dealing with the manager.
In us, work above, and programmers can only negotiate with each other, and no one is low.
The problem cannot be reproduced, but also proposed, the programmer can respond to any reproduction. The problem is there. When you come again, you will immediately call the programmer.
There is no appearance again, and finally it can be written to the report, but what is the phenomenon, but it is unable to reproduce (more serious problems so dealing with the small problem manager.).
As for the tester, you must reproduce BUG, you kill me, I have a problem that I can't reproduce each time I test, and many of the reasons I can find, some can't reproduce (only once).
This kind of thing is unavoidable, and it is impossible to say that the test personnel cannot reproduce the problem, that is, work is not in place (, the program has bug, can you say that the programmer does not work in place).
6. The test department must be independent, it is best not to be restricted by development. In fact, we must pay attention to the right to rejoice.
Our company is a project contract. To take the final item of the project, we must sign through the test department, which avoids a lot of problems. In fact, as long as you do your heart, you can say what others say.
Seven, the status we use is:
The status of programmers (submitted by testers): Wait for processing, once again.
The status of the tester (submitted by programmers): The system is not modified, the system is not modified, the system is not reproduced, and cannot be reproduced. The tester can modify the record.
The state of manager processing (submitted by tester): Administrator handles. The manager can also delete records.
According to comparative standards, in fact, for defects, there should be "waiting for confirmation", "confirmed" and "repeated submit" state, we use "waiting to be processed" to save trouble.
At the end of the final knot, the state of the defect has two kinds of "" It has been closed "(confirmed by tester or manager) and" for the next version processing, etc.).
Oh, there are many states, some cumbersome, especially when the programmer is very unclear, but I personally feel that these states are clear and easy to handle.
Eight, a netizen named Doer_ljy replied some content, I personally think that it is not very appropriate, I will reply to some content, green color is doer_ljy (battle) content:
I think there is such a problem with "I can't reproduce".
First, if you have a strict test plan before testing, it is difficult to appear "unable to reproduce". "Unable to reproduce" means that I don't know how to do this again. Then this bug is mostly "planned".
----------- None --- Enemy --- Divine --- Cut --- Line ------------
I don't know if you are testers. The word "plan" should not exist for testers. The particle size of the test case has always been a problem in the discussion. Test staff is difficult to have time and effort to write all the test cases containing all the operations, data, steps, etc. You can find all the questions, huh, huh, there is a feeling of software blue collar). Even if it is really meaningful, it is a lot of testing, it is divergent thinking, with a point of creativity, and it is difficult to consider in advance. So more time, it is perfect for the use case, etc. during the test, so it is best not to mention "plan".
Talk about a project I have now tested, there is a business, first querying the person, there is a "all choice" button, "all choice", then use the mouse one to deselect, at this time, when the business is handled, it will Tip "There is no choice person", so far, everything is normal, but this time you call the person to conduct business processing, and you will still prompt "No Choice", this is a defect. I think that the general people will not take into account the test case, because the conditions happened are very harsh: do not happen when the "Whole Collect" button; all after clicking the "Cancel the Prestern" button to handle the business Once you have happen, you will not happen before you click.
Second, mature testers can't reproduce bugs in time, and can accurately describe the operation methods of several steps before BUG, test cases. These are important for developers to analyze the cause of BUG. The so-called BUG discovery environment.
------- I - - - - - - - - - - I don't have a mature tester. Hand test, more skilled, and typing can be said, it should be, there is a lot of heart, but I am completely repeated from the head to the end, it is not easy. When writing test defects, it is only to explain the operation steps and the occurrence of operation. In fact, it is impossible to reproduce the problem, since "unable to reproduce", that is, the tester has been verified for this phenomenon, generally from the outside of the program, and the test personnel operate more than programmers.
Finally, I disagree with the test personnel without thinking about the discovery "problem" directly to the code of the coding person. After all, it is a cooperation, and the goal is consistent. Testers are always in the first scene of BUG, and should help analyze the causes of problems. Confirm that it is not his own.
---------still me--------
The tester submitted any problem, it will pass repeated verification, and if it is easy to reproduce, it will be raised. It is definitely not to be responsible, or the sentence, the structure of the program, is of course clear than people who don't do. In addition, unless the programmer is inquiry, I will not give the programmer to make modifications and suggestions! ! Test staff's task is to discover problems, and solve the problem is the programmer. This may affect the idea of the programmer's thinking; and the tester is too much, the programmer is not grateful, but may be inherently dissent (as if the programmer has a good impression on the tester).
Besides two problems I have encountered two days. The first is that our program has a function of locking data. After locking, this data will not be used in other services. I found that this feature was invalid, and I didn't have a few verification, I certainly put forward. But the programmer said that this function is good. When I verified, there is no problem, this problem can be reproduced (but I can't encounter problems, I will see it), but I haven't, but I only It can be placed there and finally closed. The second is that in an interface, entering a sequential requirement, you must first select a listbox again to enter the EDIT entry, but an operation I didn't choose Listbox, which is also saved normally. Later, no matter how I didn't have this problem (not mature enough), I gave up, and I didn't submit records (in order to avoid trouble).
Test staff's time is limited, the progress is very small, and the general use case has no time to write, and I have to spend a lot of time to verify the "unable reproduced" problem? Anyway, 10 minutes, if the test is not coming, I will give up. If you are serious, you will not know if you don't affect it.
Here are some other perspectives:
Doublefalse: If the bug that cannot be reproduced is really troubles, it is best to pay attention to the clean environment, the right operation, the same data source during the test, as long as there is a problem, it will definitely be reproduced. Oh, try! ! ! We have always had a customer to reflect the data of the warehouse, but there is no problem with the test at home, and later discovered that the Chinese character coding is misplaced, so the same word, it will become another thing. Liuxiaoyuzhou: I have encountered the same problem! Mainly to remember the environment of BUG! This is the key when we are tested! BUG we can't come here is not in place! We are here Due to the test personnel! Depressed!
Ericzhangali (another space): First, be sure to submit bugs; if you don't try to solve this bug, you have to close this bug at some point. If RD thinks is a test error, (do not understand what test error is said, is it to tell you how to do it from the time, otherwise the consequences are at your own risk,) that there is no way, if communication can not be solved, love Think about it.
Darkcat_c (wrong): No bug is not reproducible, BUG this book is an exception that appears on a standard procedure. If you do it according to Test Case steps, this class bug is not possible. As a tester must have good memory capabilities, once some bugs don't know how to generate, at least you have to know that you have roughly do it. Good analytical capabilities, although you are just testing, but you should fully understand the architecture of the program, and some important internal details, otherwise you will fail. Positioning bug is a development of development, and reproducing a bug is a progressive job of testing, do not push all things to development, or you are more than development. (Editor's note: This kind of words, do not want to refute, standard developers, maybe they should also do test)
Liyan_1014 (geese): I think it should be handled:
1, must submit bugs, must be described in detail by the Tester responsible for bugs, and the symptoms occurred in BUG, and the specific environment that occurs in BUG is clearly described; this is also a certain reference for reopening again.
2, there is a good communication between test and development. If the resulting reply is an operation error, then the developer explains, why do you allow an operation error, in general, for error control, it should be very good grasp.
3. Communication is required. Developers have a sense of satisfaction with the procedures they have completed. Generally, others do not allow others to destroy his feelings. If communication is as possible, it is a suggestive form, let Developers pointed out their own procedures and defects, so they can be accepted for developers.
The above is only experience in personal work, huh, huh ~~~~
