• info@helpingtesters.com
  • helpingtesters

Best Practices for Writing Good Defects

January 30, 2018
Writing Good defects

Defect plays an important role in software testing. Many defects arise during the development of the software application which needs to be fixed in order to deliver a quality software application to the client. In other words, we can say that writing or logging efficient and effective defect is very important part of software testing life cycle and also software development process. In this article, we will focus on how to write the good defects and what are the best practices to follow.

Defects should be reported efficiently and so be written in such a way that development team or programmers have clear picture of the defect and do not get confused or do not reject the defect in absence of proper information. Many times it happens that reported defect is rejected. It is all because the defect is not written properly or sufficient information is not provided which can help relevant development team to fix the defect. All these leads to the saying “NOT the Good Defects“. So, one should take proper attention while writing defect.

Best Practices OR Guidelines OR Tips to Write Good Defects:

  • Summary: Defect summary should be clear and concise. Development Team should be able to understand the defects without much difficulty. It should be up to the point which means that it should neither be too much longer nor it should be too short to understand.
  • Steps to reproduce: Steps to reproduce the bug should be clear. Special attention should be paid to write the steps to reproduce the bug so that development team member who is supposed to fix the bug does not get any problem while reproducing the bug. The developer may reject the defect stating it to be not reproducible.
  • Environment: Test environment should be properly written. Sometimes it happens that developer who is assigned to fix the bug finds it difficult to reproduce the bug in absence of knowledge of the environment in which bug occurred in the application. It is therefore quite important to mention the environment which includes platform/ operating system/ specific environment which makes it easier for a developer to reproduce the bug and remove any unnecessary hassle during work.
  • Information to the point: Avoid putting unnecessary details while writing the defect and try to write defect accurately putting the description with the fact. There is no need to put unnecessary and irrelevant information while describing the defect.
  • Attachments: Attach snapshot while describing the defect. Snapshot gives a clear picture of the defect and it sometimes plays the very important role in understanding the defect. Also, one should try to attach snapshot in the format such as jpg, jpeg, and gif
  • Severity and Priority: Assign a proper level of severity and priority to the defect so that development team can work accordingly, according to the level of severity and priority assigned to the defect. Also proper attention should be given while assigning severity and priority to the defect, as there are many cases where severity and priority of the defect are different and defect with less severity may have high priority and vice versa.
  • Single issue: Many times it happens that testers club multiple defects in a single defect which is not a good practice at all and tester should avoid doing this. All the defects should be separately written so that it is convenient for the development team to solve each of the issues in a proper manner.
  • Uniqueness: Check before writing the defect that the defect is written is duplicate or not. Many times it happens that duplicate entry of the defect is done without checking that the defect is duplicate or not which leads to unnecessary wastage of effort and time on the part of the development team. Many times it happens that many testers working on the same project write the same defect without knowing that this defect has been already reported. One should try to avoid such situation.
  • Analyze before logging: Do not report invalid defect. Many times it happens that testers spend hours finding the defect but is rejected by the development team. The reason behind this was that developer designs application as per the requirement and tester is unable to understand the requirement and report the developed requirement in the application as a defect. Testers should avoid such type of situation as it leads to wastage of time and effort for both development and testing team. Therefore it is quite important for the tester to clearly understand the requirement and then report the defect otherwise it will be rejected.
  • Say NO to Assumptions: Do not assume anything if the requirement is not clear. If anything is not clear tester should ask the concerned person to make the things clear before writing the defect or logging into the defect tracking system.
  • Watch for language: Avoid simple mistakes. The tester should avoid simple mistakes like grammatical mistakes or spelling mistakes while writing defect.
  • Be precise and clear: Use simple words to the development team or other stakeholders to understand the defect properly.

Overall, we can say that writing good defects is very important part of software testing life cycle and tester should pay special attention to it in order to deliver quality application product to the client.

About the author

RamPrakash Singh author

Ram Prakash has worked in various domains of testing including security, performance, security testing and automation testing. Including several tools like QTP, selenium, LoadRunner,JMeter, VSTS Coded UI, soap UI, Burp Suite etc.

Leave a Reply

Your email address will not be published.