Developer Friendly Defect Report

A defect report is a document that explains the basic gap between the expected output/result and the actual output/result of the application and the details on how to reproduce the scenarios. The primary objective of a defect report is to let the developers experience the failure themselves and it is a perfect medium of such communication.

It is very important that the basic information must be shared with the developer in any case and nothing should be kept hidden from him. Make sure that specific information of each defect is ONLY shared in a very clear way that would help the developer to reproduce the defect easily. Here are a few things that must be mentioned in the defect report for every defect in case of a mobile application.

• Defect Summary
• Defect ID
• Build ID
• Defect Type; Functional, UI, System etc
• Device/OS version
• Severity; Blocker, Critical, Major, Minor etc
• Priority; High, Medium, Low
• Module/Feature (in which the defect has appeared)
• Defect Description
• Steps to Reproduce
• Expected Result
• Actual Result
• Assigned to (only if the person is known)
• Attachments; screenshots, videos etc

While writing the defect report, it is also important that proper terms and terminologies must be used so that both the developer and the reporter have same understanding of the defect.

Enlisted are a few common mistakes (along with their solutions) that are made while writing defect report.

• Never write ‘click’ in the defect report of a mobile application. Instead write ‘Tap/Double Tap’ as these are the correct terms.

• A mobile application has ‘screens’ and not ‘pages’. Never use the term ‘page’ in the defect report of a mobile application as only web applications have ‘pages’.

• The ‘keyboard’ that only contains numeric values is called ‘Keypad’. If this ‘Keypad’ is used for dialing numbers, it will be referred to as ‘Dial pad’. So always use the specific terms while reporting the defect.

• There are two screen views. i) Landscape, ii) Portrait. Used these terms instead of writing ‘horizontal screen’ and ‘vertical screen’ for Landscape and Portrait respectively.

• ‘Drag n Drop’ is a term that is used for web applications. For mobile application, ‘slide to rearrange’ must be used.

• ‘Slide’ or ‘Swap/Swipe’ must be used when moving down the application screen instead of ‘scroll’.

• Particularly in iPhone, there is a three line button on top which is used to show/hide side menu. This button is called ‘hamburger’ button. While writing the defect report, it is mostly referred to as ‘menu icon’ or ‘side menu button’.

• The use of the following terms will also make it easy for the developers to understand the defects properly.

• Tap: Opens or launches whatever you tap.
• Double Tap: Zooms in or out in stages.
• Pan: Moves through screens or menus at a controlled rate.
• Flick: Scrolls rapidly through menus or pages or moves sideways in hubs.
• Pinch: Zooms gradually out of a website, map or picture.
• Stretch: Zooms gradually in a website, map or picture.
• Rotate: Move a picture or other item(s) on the screen in a circular direction (clockwise or counter-clockwise).

The exact format of your defect report isn’t important. You can decide what works best for you and your development team. However, the important thing is that you start experiencing bugs in a different way and that you respect your and the developers time by sharing information in such a way that helps them reproduce the defects easily.