How to write a good summary for bug report

Hello everyone!

 
Summary is a very important part of bug report. In many cases it is even the most important part. Especially if it's written well and a scope of tickets in backlog is huge.
Testers in the net walked through the announced topic through the length and breadth. There are plenty of posts, articles, discussion in communities, etc. Well, here's another one. Designed to be short, it came out a long read. Hope you find something useful here. 

Why summary is so (I do believe) important
It lets spend less time for understanding, prioritizing and remembering (after time) defects.
Testers are usually cheaper - sometimes considerably cheaper - than developers and managers, who should deal with a defect after reporting.
Thus when a tester writes a summary in a pell-mell time trying to economize her or his own time on the ticket creation, s/he usually does a disservice for all the team / project / company.
They will have to spend more time and money dealing with such a defect.
Lets respect each other - paying additional 1-to-5 minutes to summary creation (in case it's difficult to compose) will do a great favor for your teammates AND your further relationship with them.
Admit that for a tester each informative and short summary is another small brick in building strong reputation.

1. Use English words order
If you are lucky to use English in your projects, then you are naturally close to brilliant summaries.
For the case of other languages - have a look at English grammar related to words order in sentences:
[subject] + [verb] + [direct object] + [place] + [time / circumstances]
Sure thing, only relevant pieces should stay. No reason to add not useful information just to follow the grammar rules:
[ABC java script] + [fades] + [login page] + [in Chrome] + [no time here].
[iOS app] + [crashes] + [no direct object] + [no place] + [at opening native articles].
Also it's often nice to use conditional sentences:
[something] + [happens] + [when somebody] + [do something] + [place] + [time / circumstances]
[App] + [freezes] + [when user] + [changes password] + [in settings] + [after first launch].

2. Be absolutely specific or generic. No gray shades
If situation may be described very precisely in summary - sure thing to use the chance.
E.g.: "Tools page header is corrupted for 4.7 in. iPhones on iOS 10".
But if the case is really tricky, better make it generic than leave half way described.
Let's imagine that your application under test crashes after multiple actions:
user opens an application right after installation (first launch case only), logs into the system with .gmail e-mail, goes to settings, changes e-mail, saves results, changes e-mail back, does not save results, and at following attempts to launch the application it crashes.
I'd suggest here to use something like:
"App crashes when user updates e-mail via rare specific case".
It's better to identify, that case is not wide used, and that's actually the main here.
I bet that many other attempts to describe critical issues with complicated reproduction steps will rather shock your manager with worrying about CRASHes happening at who-knows-how frequent cases.
If you have many small issues related to the same feature, don't hesitate to raise aggregated tickets with a resumptive summary:
"Attaching file to CV form discrepancies".
And downstream in the ticket you describe tons of your concerns, listing them in descending order and giving them unique identifiers:
"P1 - critical issues:
P1.1 - PDF files fail to load;
...
P3 - medium issues:
P3.1 - Progress animation blinks at 90 - to - 100% progress rate.
...
C - concerns:
C.1 - Red load button looks bad on violet background."

3. Use acronyms
But do it responsibly. Use either acronyms well know in your sphere and project or be sure to encode them in descriptions inside the ticket.

4. Hisenbugs love statistics
Just to recap, hisenbugs are intermittent issues - defects without known steps for solid reproduction.
Describing such issues, please don't forget to note they are uncertain and add statistics.
E.g.: "[Intermittent, 35%]: Welcome e-mails are not triggered by ABC job".
or: "XYZ.ZYX synchronization call gets 503 error at ~ 1/10 attempts".

5. Note both Expected and Actual result where possible
Whether you have this change, just right what happens and what is expected to happen.
"Download button is green instead of blue" is a way better than
"Download button does not correspond to design"...

6. Add tags right to the summary
Task management systems are sometimes not configured really well.
Or they are, but have a limited opportunities related to tags adding, epics and other tickets linking to each other.
Once my team had to "Update website tracking with respect to new specification". That included 3 different tracking systems.
Correspondent task was already under another epic. And from developers standpoint it was no reason to split to different sub-tasks - 3 different tracking SDKs were already implemented and new updates took several minutes from programmers.
However that was a challenging task for testers.
We've linked all bugs to the epic and main developers task. And specified tracking systems right in summaries, like this:
"[Firebase]: Values of parameter A contains white spaces instead of underscores";
"[mParticle]: Parameter B is not transmitted for action C";
"[Omniture]: Parameter D gets value of page name instead of element title".

7. Is your summary short enough?
Whatever you answer to the question above, try to make it even shorter.
BTW, very often it's really difficult to make it short from the scratch and thus testers spend a lot of time crystallizing the statement. It would be considerably easier to go from draft:
just write anything you find important to the summary. It could be a loooong wording, let it be for the draft.
Now just make it shorter. And again. And once more.
Is is still informative? Ok, leave it as is and go ahead.
No? It's lost all the important information? No problem, make it generic and move your draft to description of the ticket.

8. Take your time
Somebody said once upon a time:
"To make a 10 minute speech I need 3 days of preparation.
If you give me half of an hour, I need couple of hours before start.
But if you don't limit me, I am ready, let's do it right now!"
Let yourself to think about it for a while.
Can't find words for a specific case? Have a short break, deep breath and limit yourself with, for example, 5 or 10 minutes.
That helps, I know :)
Sorry, but again: your spending this time at the very beginning of a bug life cycle will be paid off many times in the future.

9. Look what you've done!!
When you have some scope of tickets reported, take a minute and have a look on list of created bugs.
Maybe in Jira backlog, Excel spread sheet or some summary report.
Are you - who wrote it - able to identify all issues just by summaries?
Improve those which are not so good for yourself.
Now try to look at summaries like a person who knows the project background, but sees tickets for the first time.
And ask the same question.
Sure you know what to do with the answer :)


That's it.
It will take some time to learn how to write good summaries. But results worth that. Verified by QA :)
Traditionally, feel free to post your feedback in comments. As well, send specific cases and we'll try to figure out how to describe them better together!

Good luck!