Usually everyone discovers software defects, the software defect is classified, and only one can be classified, that is, it is serious, do you have any other points. For example, we encountered the following situation, the tester found that there is a function to join in. At this time, he talks with the programmer, the programmer said there is no time or unnecessary, this situation will form both. The final result can't be known, which will hurt the enthusiasm of the tester. Next time they will never consider the product, as long as you can run. In fact, this situation can be solved. Here I will mention a new software defect classification concept to effectively solve this problem.
In software defects, it is not only serious, more is that the function is not done. Speaking of everyone is understanding, it is not considered, but it will not be perfect once, need everyone's joint efforts to constantly improve. So how can you make the testers to make a good suggestion to be effectively implemented? This is what I would like to say. There is also a branching in software defects, and according to defective content, it is mainly divided into demand bugs and procedures BUG, and the benefit of this branch is to clarify the responsible person of BUG processing. We all know that the relevant developers are processed by the program bug. The following main discussion of demand bugs, demand bugs know from the name to be handled by the demand personnel, how to handle, how to effectively make these ideas in the process of processing. Now we have a BUG management system. At this time, our testers will require BUG to be submitted to the programmer, but submit to the needs analyst person, which is handled, but here I want to emphasize the positioning of the demand bug, if This bug is clearly mentioned in the software requirements instructions. At this time, it is impossible to locate it as a demand bug. It is necessary to make programmers implement, called software functional defects, and submit proceed by programmers. However, if the demand manual is not explicitly mentioned, we can be positioned as a demand bug, the process of processing is as shown in the figure.
figure 1
This is the following benefits. First, demand BUG is no longer before, no one has confirmed that the demand personnel is the demand person, which is the best because they have absolute authority for demand. At the same time, the tester is actually the earliest user. Their needs are the needs of users. This approach has strengthened the communication of demand and testers to make more efficient supplements, so that the products are more perfect. There are also testers from essentials or opposite. Here, if such a problem with the problem of software itself, there will be a situation in winning the battle, and the tester is coordinated with The relationship between developers makes them more effectively forming effective concerns about the defects of the software itself. There is also the most critical point, the passion of testers is the most important, if their ideas are not reflected, at this time, it will gradually lose interest in the test, so that the quality of the software will not be guaranteed, through this method Let them see that their suggestions can be achieved by reflecting the demand staff, let them feel that their ideas can be effectively implemented through this method, so that the enthusiasm of work will be guaranteed.
However, from the perspective of implementation, there is still a certain difficulty. First of all, let everyone change the previous way that BUG is responsible for developers, and the number of people's workload is to increase, but extensive understanding needs It is their work in their own, and I will not be very difficult. There is also a need for effective bug management tools, such as bugmanage, etc., don't say that the demand person is said, it can be forgotten in two days, this The life cycle of the demand bug will appear across two software development cycles, as some demand will be implemented in the next version, then the testers need to extend the management of these demand bugs, but I think these needs are what they put forward, they will be interested These bugs are managed. Chen Weijun
9/9/2003
