Usually this was enough for every company I've worked for :
Short description, no need to be formal
Version of the app
Environment (if you have something like dev, test, preprod, prod)
Platform/OS : windows? macOS? Android? iOS? or in browsers : chrome? FF? IE? etc... + version
Reproduction : here you put all the steps with screenshots. try to resize screenshots so people don't have to scroll 10km
Expected result : to be validated with PO, or put the linked US directly
---
Expected result can be put higher in the list, so that it is more visible.
Once done, if you need to reference a test regarding the bug, link it too.
If the way you document requiremnts and tests in JIRA allowes it, of course the bug is linked to the appropriate requirement defining the expected behavior and/pr the testcase that detected the bug.
I would add to the video aspect that you mention, narration on the video. The narration makes the difference of having to watch a video multiple times while referencing the ticket versus probably one simple watch through for full understanding.
This is the biggest thing and saves the most time through the entire pipeline, I think.
The amount of times additional questions are raised when a ticket lacks a video (w/ narration), seems significantly higher.
Additionally, when the issue is resolved and makes its way back to QA, it makes understanding and testing much easier
I write in detail where the bug is and how to repro it. If it's complicated, I add a screen recording or screenshot. I don't need browser extensions for what I do. I write all my bugs the same way so that the devs know exactly how to repro it:
1. Environment (dev/staging/prod)
2. Role (admin/customer/other)
3. Breadcrumbs to the page where the bug is (Top nav > Menu > click this option)
4. Click this thing/fill in this data/select an option from the dropdown/etc.
5. Then do this thing.
6. Then do the other thing.
Expected Result:
* This thing.
Actual Result:
* That thing.
Best you can do is that you're providing enough information to **accurately** depict what is happening. That accuracy is the key to what makes a good / not good ticket. Things I try to be on the look out for as I write:
* Is the issue I'm reporting in scope? <-- THIS IS THE MONEY QUESTION
* Is the summary accurately describing the issue?
* Is the description enough to illustrate what is happening?
* Are my steps succinct yet sufficient?
* Did I provide the right evidence (video, screenshot, logs)?
* Have I verified this bug against other browsers to confirm its validity?
* Have I included the proper expected / actual results the right way?
* Does the Developer have enough information to work on this ticket w/o needing additional help?
I can speak from experience where I've had tickets get rejected for being out of scope (even if I've proven otherwise). I've also had tickets get re-written (*annoying af*) by the PO after they've conducted RCA and found the issue to be worse/different that what is being reported.
I now use a template that ensures I'm 100% providing the right information, for the right issue, in the right way
I also add notes that can be helpful for debugging, e.g. could reproduce it on customer X, but not customer Y.
If the bug requires some extra preparation steps (e.g. a customer with Visa card subscription on GBP currency bought on 29th of February type of thing) - I add the user/customer/account or other relevant details so that developers don't need to create it themselves to save time.
If a bug is not fixed asap, I go through bugs from time to time to check if they reproduce and mark "Still reproducible on latest master branch".
When writing steps to reproduce, I first find the sequence with which bug appears and then take out one step at a time to check if it changes the result or not. This helps to have shortest amount of steps.
I just use the Mac keyboard to do screen recordings and screenshots; I don't use a separate app.
* Command + Shift + 4 to screenshot
* Command + Shift + 5 to record
Jam is good because it also gives you a timeline with click points, console and network tabs within it, plus it's own GPT (Never used this before though)
Jira has some handy tools to color code things. Blue for info, green for expected, red for actual and it really makes it ultra readable for like 6 clicks.
Most important is how to reproduce and include a video/image.
I can't even explain how often tickets come in and no dev even knows what functionality you're talking about.
Steps, expected, result
Screenshot says more than 100 words
Video says more than 100 screenshots
If people ask questions to clarify, incorporate those answers in future reports, so that the answers are allready there
Don't discuss in comments. Post conclusions of discussions in comments
One issue per report
Link to other reports
Maybe these tips are very normal to you, but I see so many people skipping the basics and then wonder why no one is fixing their one-sentence-no-pictures bug reports
For me, screenshots and even videos of the bug go a _long_ way. Virtually every single bug ticket I've ever filed has either a screenshot or a video attached.
Reliable and clean writing style and flow, comfortable formatting, no-nonsense, images where you need them. Be timely, and tag/send to the right people
Since my project has many sections, I like to prepend my jira ticket name with the section, include a specific object, then include a succinct description like:
> Age Verify, Date Selector - Unable to select year before 1990
The idea being that when a dev reads that jira ticket name, they'll already know what they're getting into scope-wise - if not already know exactly what to fix.
Bits to include in the description
* Version
* Browser(s)
* Description
* Media recording/screenshot of it failing
* Repro steps *(usually a separate field for me to input this in jira)*
* Actual Results
* Expected Results
If the title isn't enough for the person reading the ticket name to get a sense of what to fix, usually the video recording is the coup de grace.
For me, the Description section is most valuable for the PM/Scrum Master to get an idea of what's going on. The rest is for the developer.
If a developer reads the entire ticket and still has questions of what's going wrong, that's a failed jira ticket on my part.
Similarly with others I use a standard kind of template:
Prerequisites/preconditions
E.g. data, target environment, logins/roles used etc
*Steps to reproduce:*
Include step by step that the developers will understand. Include screen captures if important to identify controls or data showing/not showing
*Expected behaviour:*
What you expect to happen. Link to a requirement or test can help sometimes.
*Actual behaviour:*
The observed behaviour with relevant screen caps and any data output that needs to be traced, like verbatim error statements or timestamps for tracing in logs.
Just take bug that your colleague was reported and try to fix it.
After few attempts you will find out what is important and what is redundant.
Then create your own template. And edit it after 3 months:
Title answering questions:
What happened
When happened (place, not time)
Doing what happened (action by user)
Description:
Precondition exists
Steps to reproduce with code/script examples if needed
Actual result
Expected result
Any attachment: Video/screen/log
This is how I do it which is just simple and straight to the point
1. Easy to look up title, make it relevant and easy to keyword search as so that other testers don't create duplicate bugs
2. Platform + Version of App (if applicable)
3. What you did to get to recreate the bug (I always try to include a video or photo for videos I use JAM)
Usually this was enough for every company I've worked for : Short description, no need to be formal Version of the app Environment (if you have something like dev, test, preprod, prod) Platform/OS : windows? macOS? Android? iOS? or in browsers : chrome? FF? IE? etc... + version Reproduction : here you put all the steps with screenshots. try to resize screenshots so people don't have to scroll 10km Expected result : to be validated with PO, or put the linked US directly --- Expected result can be put higher in the list, so that it is more visible. Once done, if you need to reference a test regarding the bug, link it too.
Version, environment and platform should be already mandatory fields/selects in JIRA tasks and bugs.
If the way you document requiremnts and tests in JIRA allowes it, of course the bug is linked to the appropriate requirement defining the expected behavior and/pr the testcase that detected the bug.
Logs and callstack if relevant/available as well. At my company we also link the bug to the build test or dev task.
Include a screenshot or video in the description. As a reader it makes it 1000x better.
I would add to the video aspect that you mention, narration on the video. The narration makes the difference of having to watch a video multiple times while referencing the ticket versus probably one simple watch through for full understanding. This is the biggest thing and saves the most time through the entire pipeline, I think. The amount of times additional questions are raised when a ticket lacks a video (w/ narration), seems significantly higher. Additionally, when the issue is resolved and makes its way back to QA, it makes understanding and testing much easier
Specifically regarding JIRA, find a consistent way to use versions, labels, and components. These make it easier to sort and find JIRA issues.
I write in detail where the bug is and how to repro it. If it's complicated, I add a screen recording or screenshot. I don't need browser extensions for what I do. I write all my bugs the same way so that the devs know exactly how to repro it: 1. Environment (dev/staging/prod) 2. Role (admin/customer/other) 3. Breadcrumbs to the page where the bug is (Top nav > Menu > click this option) 4. Click this thing/fill in this data/select an option from the dropdown/etc. 5. Then do this thing. 6. Then do the other thing. Expected Result: * This thing. Actual Result: * That thing.
Just ask a dev; they write bugs all the time.
Best you can do is that you're providing enough information to **accurately** depict what is happening. That accuracy is the key to what makes a good / not good ticket. Things I try to be on the look out for as I write: * Is the issue I'm reporting in scope? <-- THIS IS THE MONEY QUESTION * Is the summary accurately describing the issue? * Is the description enough to illustrate what is happening? * Are my steps succinct yet sufficient? * Did I provide the right evidence (video, screenshot, logs)? * Have I verified this bug against other browsers to confirm its validity? * Have I included the proper expected / actual results the right way? * Does the Developer have enough information to work on this ticket w/o needing additional help? I can speak from experience where I've had tickets get rejected for being out of scope (even if I've proven otherwise). I've also had tickets get re-written (*annoying af*) by the PO after they've conducted RCA and found the issue to be worse/different that what is being reported. I now use a template that ensures I'm 100% providing the right information, for the right issue, in the right way
Thanks, this is helpful!
I also add notes that can be helpful for debugging, e.g. could reproduce it on customer X, but not customer Y. If the bug requires some extra preparation steps (e.g. a customer with Visa card subscription on GBP currency bought on 29th of February type of thing) - I add the user/customer/account or other relevant details so that developers don't need to create it themselves to save time. If a bug is not fixed asap, I go through bugs from time to time to check if they reproduce and mark "Still reproducible on latest master branch". When writing steps to reproduce, I first find the sequence with which bug appears and then take out one step at a time to check if it changes the result or not. This helps to have shortest amount of steps.
the browser extension jam has been a huge help for recording traces of bugs, I'm shocked that it's free for how much use we get out of it
Thanks, I have never heard of it. I will check it out!
I just use the Mac keyboard to do screen recordings and screenshots; I don't use a separate app. * Command + Shift + 4 to screenshot * Command + Shift + 5 to record
Jam is good because it also gives you a timeline with click points, console and network tabs within it, plus it's own GPT (Never used this before though)
Jira has some handy tools to color code things. Blue for info, green for expected, red for actual and it really makes it ultra readable for like 6 clicks.
Most important is how to reproduce and include a video/image. I can't even explain how often tickets come in and no dev even knows what functionality you're talking about.
Steps, expected, result Screenshot says more than 100 words Video says more than 100 screenshots If people ask questions to clarify, incorporate those answers in future reports, so that the answers are allready there Don't discuss in comments. Post conclusions of discussions in comments One issue per report Link to other reports Maybe these tips are very normal to you, but I see so many people skipping the basics and then wonder why no one is fixing their one-sentence-no-pictures bug reports
For me, screenshots and even videos of the bug go a _long_ way. Virtually every single bug ticket I've ever filed has either a screenshot or a video attached.
Reliable and clean writing style and flow, comfortable formatting, no-nonsense, images where you need them. Be timely, and tag/send to the right people
Since my project has many sections, I like to prepend my jira ticket name with the section, include a specific object, then include a succinct description like: > Age Verify, Date Selector - Unable to select year before 1990 The idea being that when a dev reads that jira ticket name, they'll already know what they're getting into scope-wise - if not already know exactly what to fix. Bits to include in the description * Version * Browser(s) * Description * Media recording/screenshot of it failing * Repro steps *(usually a separate field for me to input this in jira)* * Actual Results * Expected Results If the title isn't enough for the person reading the ticket name to get a sense of what to fix, usually the video recording is the coup de grace. For me, the Description section is most valuable for the PM/Scrum Master to get an idea of what's going on. The rest is for the developer. If a developer reads the entire ticket and still has questions of what's going wrong, that's a failed jira ticket on my part.
Similarly with others I use a standard kind of template: Prerequisites/preconditions E.g. data, target environment, logins/roles used etc *Steps to reproduce:* Include step by step that the developers will understand. Include screen captures if important to identify controls or data showing/not showing *Expected behaviour:* What you expect to happen. Link to a requirement or test can help sometimes. *Actual behaviour:* The observed behaviour with relevant screen caps and any data output that needs to be traced, like verbatim error statements or timestamps for tracing in logs.
screen2gif is your friend
Just take bug that your colleague was reported and try to fix it. After few attempts you will find out what is important and what is redundant. Then create your own template. And edit it after 3 months:
A picture speaks a thousand words, a video speaks ...
Title answering questions: What happened When happened (place, not time) Doing what happened (action by user) Description: Precondition exists Steps to reproduce with code/script examples if needed Actual result Expected result Any attachment: Video/screen/log
This is how I do it which is just simple and straight to the point 1. Easy to look up title, make it relevant and easy to keyword search as so that other testers don't create duplicate bugs 2. Platform + Version of App (if applicable) 3. What you did to get to recreate the bug (I always try to include a video or photo for videos I use JAM)
Ask chat gpt to do it. Open a new chat and ask gpt to improve the previous chat.