A good bug report is one that describes the problem well enough that anyone can understand and reproduce the bug, regardless of their individual knowledge of the product and without talking to the person who wrote it.”
In which the problem was found – the specific system, device, or OS, and any relevant configuration options for the test environment. This identifies if the bug is environment specific.
The general nature of a problem is often not enough to characterize that problem. One also needs to know the frequency. Is a crash always a Critical bug? No, not if it was only seen once in 6 months of development. Is a pixel alignment issue always Minor? No. not when it appears at an obvious point in every launch. Frequency can make a big difference to the overall severity and therefore priority of a problem.
The details above also give management a clear picture of the issue, and enable them to make good decisions about the priority of bug fixes. It’s good to know that the bug that Marketing is freaking out about happened only once, on an old build, and on prototype hardware.
1. A Descriptive Title
One that contains specific key words and terms to enable categorization.
not good: “Page does not load”
good: “ Contact us page - Server 500 Error when clicking on My Account”
2. Test Environment detailsgood: “ Contact us page - Server 500 Error when clicking on My Account”
In which the problem was found – the specific system, device, or OS, and any relevant configuration options for the test environment. This identifies if the bug is environment specific.
• build # of the product under development
• type of hardware on which test was run, e.g. Samsung S3, Samsung Galaxy Tab,iPhone, iPad, Mac
• configuration of hardware, e.g. 8Gb iPhone 3G, 32Gb iPad 3G, 8GB 7 inch Samsung Galaxy Tab
• OS version / build # on that hardware
• any special conditions, e.g. on wifi, after low battery warning
• type of hardware on which test was run, e.g. Samsung S3, Samsung Galaxy Tab,iPhone, iPad, Mac
• configuration of hardware, e.g. 8Gb iPhone 3G, 32Gb iPad 3G, 8GB 7 inch Samsung Galaxy Tab
• OS version / build # on that hardware
• any special conditions, e.g. on wifi, after low battery warning
3. Bug Type
Choose the correct Bug Type for the issue, for example whether it is functional, GUI or Technical. This will identify who the bug should be assigned to. Severity and Priority of the bug is also important.
4.Steps to replicate: These should start with the first thing you do like “1. point browser to www.domain.com”, include any relevant configuration steps, be atomic, be specific, end with the action that causes the problem to be visible.
Ensure all steps are clear and concise, for example:
1. Point Browser to www.domain.com
2. Click “My Account”
3. Enter email “test@test.com” into email textbox
4. Enter password “password” into password textbox
5. Click “Go”
While these steps may sometimes seem unnecessary, they are very valuable when you want to verify the bug and even more so when there is more than 1 tester testing the product. When a bug has been fixed it will be put back to the testing team to verify the fix and the only way to ensure the bug is fixed is by running the exact same steps as the original bug, without these steps you cannot guarantee the consistency of the tests run.2. Click “My Account”
3. Enter email “test@test.com” into email textbox
4. Enter password “password” into password textbox
5. Click “Go”
5. Expected Behavior
As per the requirement document/design document
6. Actual Behavior
Actual behavior observed by the tester.This allows the rest of the group to identify if this is actually a bug or if the product is working as designed.
7. The severity of the issue.
When this happens, how bad is it?
It’s important to be clear on your reasoning as to why you have given the severity you have, so that others can understand and support your decision. One note to remember, your job as a tester is to give the bug a severity level THIS IS NOT PRIORITY – it is the Stakeholders/Project Managers decision to give the bug a priority level which will take into consideration many things including the severity you have given.
8. The frequency of the issue.
How often does this occur? Always? Once?The general nature of a problem is often not enough to characterize that problem. One also needs to know the frequency. Is a crash always a Critical bug? No, not if it was only seen once in 6 months of development. Is a pixel alignment issue always Minor? No. not when it appears at an obvious point in every launch. Frequency can make a big difference to the overall severity and therefore priority of a problem.
9. Evidence
Some of the evidence that you could supply is as follows:
• A user story this allows anyone reviewing your bug to identify what you are trying to do and also puts the bug into a scenario
• Screenshots
• Video/recorded screen share
• Log Files
• Browser matrix (if web based testing – a list of all browsers that are affected by the bug)
Although the above may seem like it requires a lot of time and work, an extra minute spent adding the above information to a bug report can stop the back and forth between development team and tester along with hours of engineering time, if it keeps someone from investigating the wrong thing, on the wrong device, without knowing that it only happens on the local network with yesterday’s build.• Screenshots
• Video/recorded screen share
• Log Files
• Browser matrix (if web based testing – a list of all browsers that are affected by the bug)
The details above also give management a clear picture of the issue, and enable them to make good decisions about the priority of bug fixes. It’s good to know that the bug that Marketing is freaking out about happened only once, on an old build, and on prototype hardware.
You’ll find that bugs that are clear, especially those that provide a test case in the form of a sample project, will get investigated and resolved more quickly. You will also build credibility as a tester and you will be taken more seriously in your role.
No comments:
Post a Comment