Defect classification and management: requirement defects vs program defects

Source:
51 Testing
------------------------------------------

Generally, Software defects are classified when they are detected. There is only one way to classify software defects, that is, serious defects. Isn't there any other method. For example, when we encounter the following situation, the tester finds that a function must be added. At this time, he and the programmer say that the programmer says there is no time or unnecessary, in this case, the two sides will be involved, and the final result will not be known, which will hurt the enthusiasm of the test staff. Next time they will not think about the product with all their heart and soul, you only need to run it. In fact, this situation can be solved. Next I will mention a new software defect classification concept to effectively solve this problem.
Software defects are not only serious, but also not functional. It may be understood that the demand is not taken into account, but the demand will not be perfect at once. We need everyone's joint efforts to continuously improve it. So how can we effectively implement the suggestions put forward by testers? This is what I want to talk about below. There is also a division of Software defects, which is divided into requirement bugs and program bugs. The advantage of this Division is to clarify the owner of bug handling. We all know that program bugs are handled by relevant developers. The following mainly discusses the demand bug. From the perspective of the name, the requirement bug should be handled by the demand personnel, how can it be handled, and how to effectively embody these ideas in the process of handling. Now we all have a bug management system. At this time, our testers will not submit the required bugs to the programmers, but to the requirement analysts who will handle them, however, what I want to emphasize here is the positioning of the demand bug. If this bug is explicitly mentioned in the Software Requirement Specification, it cannot be located as a demand bug, it must be implemented by programmers, known as software functional defects, and submitted for processing by programmers. However, if the requirement specification is not explicitly mentioned, we can locate it as a requirement bug and handle the process.

This solution has the following benefits: first, the demand bug is no longer as before, and no one confirms it. The demand handler is originally the demand engineer, and it is best for them to confirm and track it, because they have absolute authority for their needs. At the same time, testers are actually the earliest users, and their needs are users' needs. This method enhances the communication between the testers and the testers, so that the requirements can be effectively supplemented, to improve the product. In essence, testers are still opposed to programmers. If the problem is not a software issue, in this case, the entire war will be lost after winning the battle. The testers should coordinate the relationship with the developers so that they can pay more attention to the defects of the software. Another key point is that the passion of testers is the most important. If their ideas are not reflected, they will gradually lose their interest in testing, therefore, the quality of the software cannot be guaranteed. This method allows them to see their own suggestions and reflect the requirements of the personnel, they always feel that their idea is that they can be effectively implemented through this method, so that their work enthusiasm can be guaranteed.
However, from the implementation point of view, there are still some difficulties. First, let everyone change the previous idea that bug is the responsibility of developers. Second, the workload of the required personnel should increase, however, it is not very difficult for them to get a broad understanding of their job. There is also a need for effective Bug management tools, such as bugmanage. Do not say something to the requirement personnel, if you forget it in two days, the life cycle of the requirement bug will span two software development cycles, because some requirements will be implemented in the next version, in this case, testers need to extend the management of these demand bugs, but I think they have raised these requirements and are interested in managing these bugs.