We use different formalisms in titles/subjects for different purposes (story, feature, test), but we have no formalism for bug reports...
We are investigating the advantages of a standardised title format for bugs.
Different formalisms for titles/*subjects* in use, practically
We use with quite a success these formalisms in titles/*subjects* .
For Scrum stories, we use the following title formalism:
As a <role>, I want <goal/desire> so that <benefit>
For FDD (Feature-Driven Development) features, we use the following title formalism:
<action> the <result> <by|for|of|to> a(n) <object>
For Acceptance Tests (behaviour), we use the following formalism:
GIVEN THAT <conditions>/<initial state>/<context> (no action) WHEN <actions> (performed by user) THEN <expected results>/<consequences> (that the system does)
Looking for a bug title formalism
For bug reports, we think we are going to adopt a title formalism close to:
I was <context>, I did <action>, I got <actual behaviour>
I only focus here on the title, not the full description!
- homogeneity across teams (when bugs needs to be passed over)
- strictness for better description and understanding
- mapping of:
- the bug's 'context' to the acceptance test's 'context'
- the bug's 'actual behaviour' to the acceptance test's 'expected results'
- it is a change to introduce, document, promote, and followup in the project
- you name it
Guidelines for the title/subject
But this formalism is not enough for just a title, as it may need a few guidelines:
- should be as short as possible
- do not mention a technical component or feature, as the guess and confirmation is part of the investigation and not the purpose of the creation of the bug
- do not make any assumption or guess
- just basically describe as briefly as possible the context, action, and actual behaviour, because anyway it will be detailed in the full description
- do not not add any markup like [stuff] or (thing), because it hinders the reading
- do not add any team-specific keywords, as a bug is supposed to be passed from team to team
- do not try to solve the issue at the reporting phase, it is the task of the assignee
- bring the right balance/dichotomy between barely perimetered issue, and fully understood, as in one hand it is too vague, and on the other hand the resolution is almost finished
- stay meaningful
Full description (not the goal of this post)
Of course, this is not the goal of this post, but in the full description of the bug free text), there will be:
- Steps to reproduce
- Actual behaviour
- Expected results
- links to docs
With all the fields of the bug tracker software, like affected/fix versions, severity, priority, links to other tickets, etc.
But this is not the subject of this post...
Let's get back to the bug titles/*subjects*.
Open questions on bug titles
- Do you think it is worth to put up such a title/*subject* formalism in place?
- How do you name you bugs? (how you fully describe and manage bugs is not the goal of this discussion)