How to Write A Great Bug Report

I am an odd sort of person. Why? Because I love a well written and descriptive bug report. I love a case that includes clear and easy to follow reproduction steps. I love a written bug report that includes all the necessary information on versions, configurations, connections and other system details. Why? Because I believe in efficiency. I believe that as an engineer I have a duty to generate value to my employer or customer. Great bug reports are one part of our collective never-ending goal of improving team efficiency and increasing the value we generate as engineers, quality assurance staff, or even as a customer.

What does a *bad* bug report look like? Find out more by reading my entire post over at EmbeddedRelated.com. Looking forward to your feedback and suggestions!

2 comments

  1. Totally agree with you here. Funny how companies QA can allow these sort of practices. When I was brought in to restructure the qa department where I’m currently now the former SQA analyst was logging 15 bugs into one report. I was shocked but seeing the state of the company at the time I was not surprised. Really simple protocol if you ask me. For every bug log a case with environment, equipment used, repro steps, expected and actual results, video, audio screenshots, logs if any. With the above developers can quickly fix the problem with no delay of releases. Also you will gain trust and respect of developers which is most important.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Discover more from Cove Mountain Software

Subscribe now to keep reading and get access to the full archive.

Continue reading