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.