An insight to Beautiful Testing Book - Chapter 6
Chapter 6 for beautiful process starts with a bizarre situation. One of the Harvard University's engineering note books has a bug cello taped to it and have a interesting story of the first actual bug.
Although the note is very very old and found in a museum, the bug report contains two important details that need to be there in every bug report. They are as bellows;
1. Mentioning the root cause to the bug report.
2. Associating the bug closely with the test procedure.
The reason for demanding the attachment of root cause to the bug report has a very simple consideration. That is for the others to benefit from it. So when there are different implementations from a single product done by different set of people then they can eliminate the common bug and improve their implementations if they are known to the root causes of the bugs their product has.
Most people do not consider bugs as important. But there are situations where people's lives rely on the correct operation of software. For an example the wrong behavior of a scanning machine or a aeroplane may lead to disastrous situations. Therefore it is important to consider defects of software seriously rather than superficially laughing at the words "bug management". That is why bug/defect management is so important.
The book says that the very initial thing to do in defect management is identifying the defect. For that it is important to consider some vital aspects of a defect. Some of those aspects are; Who,What, When and Where.
1. Who
A good defect tracking system should tack some important details, such as who logged the defect, who fixed the defect and who verified that the defects have been fixed. Ultimately the defect is considered.
A bug report should consist of the bug's characteristics and also the conditions for the bug to re occur another time. So that the fixing, verification and also the elimination of the bug from newer releases are made easy.
A bug report should essentially posses following details.- Description - A summary of the bug.
- Detailed Description - Sufficient details to re occur and see the bug which is reported.
- Priority - Importance of the bug.
- Severity - The impact of the defect.
Priority and Severity..... Confused?
For an example lets say that we have developed a web application for a customer. And it's some of the content could not be properly displayed on the customer's standard web browser. Then the bug is of high priority. Lets say the same content is not displayed in an archaic version of the web browser that they are using then we consider the bug is of low severity.
3. When?
Defect might found at different stages of the software development life cycle. Some bugs may found at Quality Assurance testing and some may found after releasing the product to the customer. If the bug is found at the latter stage then the cost of fixing the bug is very high. So that it is necessary to identify and fix the bugs at the earlier stages.
4. Where?
Some times the bug may found at the public open source defect tracking system. Then there will be a problem for the developers or Quality Assurance to find the code base that the defect lies in.
For a developer it is very easy to find the source code where defect lies in, if they are known about a defect. But for an end user or a support person always the defect they found is existing in the product or the distribution. Because they are unaware of the source code of the product. They can not relate the defect they found of the product to the actual code base. So that the communication of the defects will not flow very effectively. This is a very big disadvantage.
So that there exist a good solution for this problem. If mentioned in simple terms, we can use the Original defect repository and extract some lesser information about a bug and place it in a local mete database. And create a key which links the local meta database to the original defect database. So that what happens is the public community can interact with the local meta bug database and apply tags to the bugs and they are tracked. Similarly the company Quality Assurance team can interact with the original defects database and this will provide an effective bug communication methodology. The bellow diagram will provide some insight to defect information communication.
