To prepare a concise and clear report of the bugs occurred during testing/debugging to convey the performance report of an application, it is very necessary to present the details in a manner that is easily comprehensible.
Following is the list of bug reporting components:
Defect Identifier – It is simply a sequentially generated number that represents a defect uniquely. It increments as the defect log increments.
Summary – A summary is an overall description of a subject in brief. It highlights the key factors resulting in the defects.
Description – The description section entails writing down the very nature of a defect. It helps to track down the root cause of the defect.
Severity – Severity states the extent to which a defect can harm a system, business operation, and other fact associated with it. Generally, the severities are ranked as per an organisation’s definition of the same. The categorisation of defects can be explained as follows :
S1:Critical – This indicates that a defect needs to be dealt with as soon as possible without any delay or negligence. For instance such a situation may arise in the event of the application not getting installed on the machine.
S2:Serious – A major part of the application may not be working properly or at all and there is no alternative but to fix it immediately.
S3:Normal – A defect for which an alternative can be thought of, as a temporary solution.
S4:Cosmetic/enhancement – This is some minor issue that occurs while operating the application. For example – pop-up ads appearing after every few minutes.
S5:Suggestion - This is generally an opinion or suggestion to improve the existing functionality. This may be related to UI.
Priority – Now once the degree of severity has been identified, the next step is to assign priorities to the defects as per which they are to be addressed. Priority criteria takes into account the impact on the business it may have. Priority has its own set of classifications based on the severity levels.
P1 – urgent : Needs immediate attention
P2 – high : Needs a resolution in the next external release.
P3 – medium : Resolution is required in the first deployment.
P4 – low : Resolution required for future subsequent releases.
Date and time– This element is generally used for searching the list of defects occurred on a specific date or those that were identified prior a particular software release.
Version and build of the software under test – Often during a software release, there have been a bug fix or an enhancement to the application. Due to the fact that there exists many software versions, it is noteworthy as to which version of the software introduced a defect.
Reported by– It is important to mention the name of the person who raised the defect because in future scenarios, it may be easy to cross reference the details.
Related requirement– Once defects are detected, one can map the same with the requirements. Hence it can be noted what requirements have been impacted due to such failures.
Attachments/Evidence– Any evidence that reflects presence of any failure are sent along with the defect report. This helps the developer or reviewer to analyse the defect better.
.png)
.png)
