6

Bug report title is very important to distinguish one bug from another without opening its description (steps, attachments). If we will not name them in appropriate way it would be:

  • lots of duplicates
  • many questions from project manager (What is it about? Is it really severe?..)

If testers have access to the console log, is it appropriate to use exception names in defect title?

E.g.: When 'Print contract' button is pressed, message "Provider org.apache.xalan.processor.TransformerFactoryImpl not found" is displayed in console-log.

Or: "java.lang.OutOfMemoryError: Java heap space." after 4 hours of work

Reason to use is that two different parts of software could arise a bug which originates from one place. TransformerFactoryImpl not found could crash stuff in different parts of software so why do we need to create dozens of bugs?

3

We should not use exception names as Bug Titles:

  1. Bug Title - Its expected to tell the story about bug in a single straight & clean sentence
  2. We should always title a bug according to its behavior.
  3. According to me, good practice to title bug will be - simple english sentence which speaks about behavior of application This can be easily recollected and recognize by everyone as you mentioned like Tester, Developers, Manager & leads
  • 1
    So how would you recommend handling the situation where the bug title would be When 'Print contract' button is pressed, an error is received? This button could potentially have multiple errors where this title is appropriate. How would you distinguish them in the title? – liebs19 Aug 10 '16 at 13:10
  • 1
    Its a real scenario that one any button action we may face different issue due to different errors. In your case, I will suggest title: When Print contract button is pressed, error <specific> is observed/received. So even we can identify with other bugs. I will not write error occur in code, I will add what impacted on behavior and what end user can observe. – NarendraC Aug 10 '16 at 13:30
2

I personally recommend against using exception names as bug titles:

  • A bug title should serve as a summary of its bug report, exception message is not really friendly to read as daily, casual English
  • Some testers who read your bug reports are not necessarily technically minded, manual testers especially UAT testers do not have to know anything about coding, when they read exception messages, they will become more confused and dis-encouraged from reading on.
  • Business analysts read bug reports too, and many of them do not come from a coding backgrounds.
  • How about managers? Not all managers know how to code.

I would write an easy to read, casual English sentence as a bug report title.

2

Maybe.

My internal customers use it all the time since it's the best way to describe the symptom they see, but I can easily see cases where this will be inappropriate or not useful- public records where you don't want internal code snippets published, exceptions coming from an upper layer (UI maybe) irrelevant to the underlying problem etc.

2

Depending on who will read the report.

You can use other keywords/labels to group/find the common issues and see is the bug was already reported or not.

There is no need to use code/strack-trace in the title, you need a title that is concise and describes as simple as possible the issue found. In this way you can avoid any misunderstandings.

If you need to provide a status of the build or create a build report page, you need to keep in mind who will read that page, who will need that status (pm, qa team, the client).

For other details like stack-traces you can use description section.

You should create/have a documentation page that describes how to log a bug and the team should follow those rules in order to decrease the duplicates, the misunderstanding and to increase the work efficiency and high level status of the build.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.