Industry Opinion

« back to blog listings

How to report a defect? - Need for a common defect template

As  features and functionalities develop in the automotive systems the complexity of the software systems also develops, which in turn contributes towards a significant amount of defects being introduced in each engineering phase.

The effort and time spent finding a critical defect in automotive software systems is often as much as used in developing a new feature. Once a tester finds a defect he/she will report the defect in the defect tracking tool in their own description style.

Some testers will write a ticket with lots of information, while others may write minimal information, usually in a cryptic form or one liner.

Since there is no common defect description followed among testers, the defects reported by the tester  become very difficult to understand by  developers and also by fellow testers.

During the defect lifecycle, there will be lots of mails / calls  between  developers and testers to understand a defect better and to solve it as early as possible.

So, how does one understand a defect better? Is there a way to report a defect in an understandable form? Here is my proposal to the testers.

By following a common defect description template, all the testers can write the description of the defect in a consistent and understandable manner. This will help the developer to understand the defect better, with no or minimal interaction, and fix it on time. This template will serve as a common language among the testing fraternity to better understand the defect.

Here is a snapshot of the common defect description template:

Title: Specify the short description about the defect. (Preferably one line, to tell about the short overview of the defect)

Precondition: Specify the entry condition for the system (the normal state of the system, before the defect is identified)

Action: Specify the sequence of input(s) given to the system

Observed result: The system’s observed behavior as per the requirements

Expected result: The system’s expected behavior as per the requirements

Recovery condition: Specify the recovery procedure from the error condition

Reproducibility: Specify the reproducibility criteria, such as the number of times the defect can be reproduced

Note: Write a short note on the similar occurrence of the defect in a different application or in a different test environment

Reference: Specify the requirement specification document name with reference to the Requirement ID

Conclusion:

Once the testers and developers start using the template the time taken to fix a defect reduces drastically. This template has become a standard to report the defect in the business unit and also among the suppliers who test the product.

R. Rajkumar, project manager, Robert Bosch Engineering & Business Solutions Ltd

There are currently no comments.