Bug 2-"true sense"

Originally published on 11:23:21

When introducing the glorious history of bugs, the bug was inadvertently covered with a mysterious veil, as if the bug was a distant and mysterious thing, as in the pyramid. In fact, the bug itself is not so mysterious.

 

First, let's give an official definition from Ron Patton software testing:

>>>>>>

 

A software bug occurs only when at least one of the following five rules is met:):

1)The software does not implement the features required by the product documentation

2)The software has errors that should not have been specified in the product manual.

3)The software implements features not mentioned in the product manual

4)The software has not implemented the goals that should be achieved, though not explicitly mentioned in the product documentation

5)The software is hard to understand, difficult to use, slow to run, or-from the tester's perspective-the end user will think it is not good

<

 

 

I will not go into details about the "official" explanation above. "copying" is meaningless, so if you need to know more, read the original book "software testing" (Ron Patton). From my own experience, the so-called bug can be roughly divided into "what to do is not done, what to do is not done, what to do is not done as required ", I simply classify bugs.

 

The so-called "Do not do" contains three parts:

Do not do what is required in the product manual

Ø there are no clear requirements in the product manual (listed separately as a project) but should be implemented

Ø not mentioned in the product manual, but the tester thinks it should be done

The above three situations of "do not do" should be treated differently. For the first case, it is very direct. The features listed in the product manual are not implemented and submitted directly as bugs; the second is a little more troublesome and requires a unified understanding with developers. The third is even more troublesome. At this time, developers need to work together with project managers to test the total, after a unified understanding, you can decide how to handle this bug.

 

The so-called "something should not be done" is the most difficult bug for new testers and developers to understand, it does not mean that its concept or meaning can be solved by reason, but the "Understanding" of the perceptual layer ". Imagine that a new feature was not easily implemented by developers, but the tester asked to delete it with the "product manual". Most people may think that the additional features are always good ...... However, it should be noted that each additional function has the risk of introducing additional bugs. This not only increases the test workload, but also increases the product quality risks. More importantly, whether the rationality of the added additional functions is determined. For example, if we develop a course management system, under normal circumstances, the product manual requires that common users only have login and browsing functions. In this case, if developers provide other additional functions such as search, sorting or even editing, which may cause problems. These additional operations will increase the burden on the system or server, and even cause security problems. Of course, for the problem of "something should not be done", you need to find the relevant developers and PM to determine, the testers should not be self-righteous as bug submission, as to the reason, it will be mentioned in subsequent articles.

 

The so-called "not do as required", the requirements here refer to "what should be done", these content is determined according to the product manual, such as a "position" option, the product manual clearly states that the "drop-down box" is used for handling, while the developer only uses the "text box", which are all bugs. For this type of Bug, it is relatively simple to identify and handle, and most of the bugs we find are also of this type.

 

The bug definition has not yet been "officially defined", which is why I used "officially defined" When referencing Ron Patton. The bug mentioned above always carries a relatient "product description". In fact, this is not found in many software projects in China. Therefore, in the project practice process, the content mentioned above should never be difficult. As for how to handle it flexibly, I will also mention my personal opinions in subsequent articles.

 

The above for personal opinions, if you have suggestions or need to communicate, please contact unique.wuchaodong@hotmail.com