Bug type : Visual or Content ?
Title : Provide a short, descriptive title for your bug
Url : Provide the URL where your bug occurred
Steps : Add steps
Result description : Describe the actual result or behaviour for this bug
Expected result : Describe the result or behaviour you expected for this bug
Does it matter how you describe the bug? A bug report is just a communication device, and your audience might be some sort of management type wondering which bugs to investigate, and a coder who might fix it. Knowing that you might even be able to walk on over and tell them. You also might ask what information they want so that you can include it.
If you’re using a video to describe a bug to me so that I can then write down how I’d describe it to someone else, then why can’t you use the vide to describe it to them? I used to use gifs all the time when showing a bug.
Have you investigated the bug? Do you know why it occurs? If the URL of that image doesn’t point to an image then the bug is “the URL is incorrect”. If the URL is correct but the image isn’t where it’s supposed to be then the bug is “the image isn’t where it’s supposed to be”. If it’s part of some function that generates a URL from some other image but it broke because the image file had some weird character in it, then the bug is “the function that generates the URL fails when the image file name contains [some weird character]”. It’s most useful for people who care about this bug to know why it’s occurring, or at least what you checked for so they don’t have to chase it down when replicating. You might find more bugs as you’re chasing down this one!
Can you recreate these circumstances? Does it always occur with the same images, or is it always the 4th and 5th items in this list? What if you click on those items, is everything okay with the content of those pages? Right now you have a symptom of a problem but you don’t necessarily know how far that extends or why it might occur in the future (in front of someone who matters, like a client or a client’s customer).
I don’t know what the difference between a visual and content bug is. There’s stuff wrong with the content that you used your eyes to find, so I’m stumped, you’ll have to talk to whoever wrote this template about that.
When describing any bug you’re trying to get useful information to people who need it, so that’s the bottom line. If you are constrained by some template then I’m sorry, but honestly you can probably make the points you want to make
Hope any of that is helpful. If it’s not then I’d like to know more details on the problem you’re having with the description.
Bug Visual
Title : Images for “SKU 202036” and “SKU 205575” are cut off in “You recently viewed” section on the website
Steps :
Open the site.
Scroll down until you will see the cattegory “You recently viewed”
Scroll the images to the right until you see “Image for SKU 202036” and “Image for SKU 205575”.
Result description : The images for “SKU 202036” and “SKU 205575” are cut off in the “You recently viewed” section on Dummy.com. Instead of showing the complete images, only a portion of the images are visible, and the rest is cut off. This makes it difficult for users to view the entire image and get a clear idea of what the product looks like.
Expected result : The images for “SKU 202036” and “SKU 205575” should be displayed in their entirety in the “You recently viewed” section on Dummy.com, without any parts of the images being cut off or obscured. This will allow users to view the complete product images and make an informed purchasing decision.
Who is saying there’s something wrong with it? If you’re trying to pass a test/interview that’s a different situation to satisfying a manager, for example.
The most obvious missing element is the system you tested it on. It’d be most helpful to add the browser you used, because some browsers use different rendering engines. Mobile operates differently from desktop. Your screen resolution might affect the outcome. So platform, resolution and browser are a good start.
Also, the images are not cut off, they are “broken”, usually meaning that the URL pointing to it is wrong, or is pointing to an image that doesn’t exist. The web page will contain a pointer to where the image is hosted. For example if you (on desktop) right click on the little ninja guy at the top of this page and click “copy image address” (or whatever your browser calls it) you’ll find that image lives at “https://global.discourse-cdn.com/business7/uploads/ministryoftesting/original/2X/8/8bc6e303df3bb221451a35d979095a67b3777e8e.svg”. This web page that you’re looking at right now has code in it that says to put the image at that address into that space on this web page. If that URL were wrong, or that file didn’t actually exist at that address, the browser would show a broken image icon instead, which is the browser saying “hey, this page asked for this file but I cannot find/display it, so here’s a broken image icon instead”. If you search for “broken image” you’ll find information on this.
In an actual business as long as you give the people who matter the information they need then your bug report is correct. If you give them information that’s easy to read and use, like that video, then your bug report is better. If you explore the problem to simplify it to make it specific then that’s even better.
I think, what Chris is also pointing out that there are broadly 2 kinds of bug reports that come to a developer. Bugs that just say,
Hey this does not look right, take a look here!
Ones that help a developer to fix the bug by specifying how to repro the issue, why it is a undesirable behavior, and what it’s impact is.
I would expect developers to spot the first kind themselves actually, when they check the MVP happy-path and before they merge code to a dev branch. And this all speaks to how much a defect costs the company, the second kind of defect report often costs more, because it gets found later? Because it’s harder to spot, it’s going to be harder to reproduce.
And frankly when a tester does some work to attempt to properly find the exact cause and look at the internals to find the cause, they sometimes find that a defect is caused by the deployment or integration environment. Things like trying different browsers and so on. Often something they can directly help to fix without needing the developer team and 5 minutes of team time to triage sometimes if it’s a CDN or environmental cause. Anything you can do to speed up the triage of a bug reduces cost to the company if you can add answers to questions the devs are likely to ask about the bug seen up front, before the triage meeting! My pet hate is people attaching a full log-file, that is going to cost time to read, zone in on the exact place in the log, and why you think it’s pointing to the fault. That’s why we add detail, to answer common questions, the detail we add is context specific, there are no detail rules.
But I do love repro videos, they have a lot more use than just showing the bug.