SOFTWARE BUGS : GENERAL CONCEPT

Software Bugs Definition

                A software bug is a coding error in the computer program causing it to crash or produce invalid output and other defective behaviour. The problem is usually caused by insufficient or erroneous logic. A bug can be an error, mistake, defect or fault, which may cause failure or deviation from expected results. Most bugs are due to human errors in source code or its design. There is no program without bugs but a program is considered to be buggy when it contains a large number of bugs, which affect program main functionality and cause incorrect results. Even after a product is released or during public beta testing, bugs are still apt to be discovered. When this occurs, users have to either find a way to avoid using the “buggy” code or get a patch from the originators of the code.

Debugging

Debugging, is a multistep process that involves identifying a problem like bugs and other program error by isolating the source of the problem, and either correcting the problem or determining a way to work around it. The final step of debugging is to test the correction or workaround and make sure it works. These are some steps in debugging :

1. Reproduce the problem.
2. Describe the bug. Try to get as much input from the user to get the exact reason.
3. Capture the program snapshot when the bug appears. Try to get all the variable values and states of the program at that time.
4. Analyse the snapshot based on the state and action. Based on that try to find the cause of the bug.
5. Fix the existing bug, but also check that any new bug does not occur.

Bugs Classification

Bug/ defects can be classified according to several criteria based on the impact on users (criticality) the necessary effort to correct the defect, the component where this defect is initially present, etc. Defect classification enables us to order them according to various criteria and to take measures in order  to avoid repeated reporting of already discovered defects.  The measures and fixes that will be done are based on the RPN (Risk Priority Number), the RPN are numbers that are given based on the severity and priority of the bugs, the RPN can be ranged from 1 ( the most critical) to 25 (the most trivial).

Severity means the impact, can be immediate impact or delayed impact, of a bug on the system. The same scale can be used for failure mode and effect analysis (FMEA:

1. Loss of data, hardware damage, or a safety issue
2. Loss of functionality with no workaround
3. Loss of functionality with a workaround
4. Partial loss of functionality
5. Cosmetic or trivial )

Priority to capture the elements of importance are not the same as severity, such as the likelihood of occurrence in actual customer use and the subsequent impact on the target customer. When determining priority, you can also consider whether this kind of bug is prohibited by regulation or agreement, what kinds of customers are affected, and the cost to the company if the affected customers take their business elsewhere because of the bug. Again, scale like the priority scale used in the FMEA can be used in measuring priority. 

Bugs Reporting

                Bug report is the document including the information about the defect, its description an all required attributes. The Bug report must be carefully written for the person or organization can understand the problem and fix it with the minimal time and cost.

Some number of bug reports will always be irreproducible or contested. Some bugs exhibit symptoms only intermittently, under obscure or extreme conditions. On some projects without clear requirements, there can be reasonable differences of opinion over what is correct behavior under certain test conditions. Sometimes testers misinterpret test results and report bugs when the real problem is bad test procedures, bad test data, or incorrect test cases.

Bug eports components :

1. Structure: a tests that deliberately carried out while taking notes enable us to find more easily the first indices of a defect;
2. Reproduction: the reproducibility of an anomaly is a necessary attribute to ensure its correction;
3. Isolation: once the defect is reproduced, it is important to isolate the phases leading to its occurrence. Where possible limit the number of steps necessary to reproduce the defect. A defect including seven stages or more is generally difficult to read and its correction will thus be delayed;
4. Generalizing: once the defect is isolated, we need to determine whether it can be generalized. This includes the detection of other defects of a similar structure in other modules of the software;
5. Comparing: determining whether the defect has occurred for the first time in this version of the application or whether it was already present (but undetected) in previous versions;
6. Summarizing: the title of the defect (or its summary) is critical and must show how it can affect customers;
7. Condensing: reducing the size of the defect report so as not to bore readers and reducing the number of acronyms so that it remains readable;
8. Ambiguity: avoiding any ambiguity is important, in order not to be vague or subject to misinterpretation;
9. Neutrality: the anomaly report must be neutral and not be perceived as an attack against developers;
10. Review: once the defect has been written, it should be reread by another tester.

References :

https://searchsoftwarequality.techtarget.com/definition/bug

https://searchsoftwarequality.techtarget.com/definition/debugging

https://economictimes.indiatimes.com/definition/debugging

Rex Black. (-). Managing The Testing Process. 03. Wiley Publishing Inc. Indianapolis. ISBN: 978-0-470-40415-7.