What is a bug?
A bug (also named 'fault' or 'defect') is an unexpected behavior in the software. A bug can be something the software should do but it doesn't do it or doesn't do it in the right way. A bug can also be that the software does something it shouldn't do. Usually, users don't like bugs. Occurrence of bugs, especially critical ones can cause users to stop working with the software.
Why bugs occur?
There are several reasons that can cause a bug. Let us mention some of them:
Unfinished requirements
Requirements that are not detailed enough
Requirements with multiple meanings
Logic errors in the design documents
Code errors
Not enough sufficient testing
Misunderstanding of user needs
Lack of documentation
Bug priority and severity?
We prioritize the bugs because we can't fix everything and we need to decide what we should fix first and that means that we prioritize what should be tested first. One parameter for prioritizing a bug is the bug's severity.
We define severity as the impact on the customer/end user. There are 4 common levels of severity:
Critical – software crash, hang, loss data, corrupt data
High – causes serious problems to the user
Medium – causes problem but the user can work around it
Low – trivial issues like spelling mistakes
Of course, you can add more severity levels as long as you well define each severity.
As testers we can add suggestions. A suggestion is not a bug. It is a request or a change that we think will give some added value to the system. If the project management will decide to add it then it will become a new requirement that will be tested as other requirements.
Let's take for example an office word software and review the bugs severity. A critical severity bug will be if the system will crash every time we send a document to the printer. A high severity bug will be if "Save" and "Save As" functions will not work. We understand that this unworking feature has a high impact on the end user. A medium severity bug will be if the "Save" function does not work, but the "Save As" function works well. The user can't do "Save" but he can work around it using the "Save As" function. A low severity bug will be if instead of "File/Send To" it will be written: "File/Sent To".
How to report a bug?
Why is it so important to report a bug?
Reporting a bug helps the programmer to reproduce the bug and to solve it.
It helps us to retest and see if the bug was fixed and if the fix is correct because we know what the bug was and how to try to reproduce it.
This is our product. We know how to find bugs. This is how we can show our knowledge and value to the project management.
You need to report a bug in a certain way. What can happen if we will report the bug in an improper way?
The programmer will not be able to reproduce it and fix it.
We will not be able to test it or our testers coworkers will not be able to retest it again because they will not understand and we will not remember what we meant 3 month ago when we report it.
The programmers might think we are not professional testers because they can't reproduce the bug.
The ping pong game – a programmer deliver to the tester because he doesn't understand the bug, and the tester deliver back to the programmer until the bug is fixed or it is thrown away.
Steps that are needed to be done before you report a bug in the bug tracker system:
Try to reproduce the bug at least one more time.
Search the bug in the bug tracking software. If it exists, check if you can add valuable information, if it doesn't exist, you need to report it as a new bug.
Steps to write a bug:
Write a short and meaningful title which describes the bug.
Write a description of the bug, what should be the correct result, the error message and any information that can help the programmer to isolate the bug.
Write how to reproduce the bug by breaking steps logically:
Straightforward path to trigger the bug.
Describe the steps.
Check that the bug is reproducible
Very bad example:
I can’t login to the bank account. Try to go to the account and you will not be able to do so.
Good example:
I am unable to log in to the web site.
Open IE 6.5 on window XP.
Enter the bank account URL (www.bank.co.il) in the location bar and hit enter.
Insert "user1" in login name field.
Insert "123456" in password field.
Click “login”.
Result: nothing happens, the system does nothing.
It should log you in because this username and password are exist in the database.
It was a very high level description of how to report a bug. Usually we will add more information such as:
Short but clear and explanatory short description – the reader should know the essence of the bug from it.
Enviroment setup - in here we will add the related configuration dimensions such as: site, setup, all software used and versions, all hardware used etc.
Full description of the bug - try not to repeat the short description of the bug. In here we will explain how the bug affects the end user, if it is not trivial, and what cannot the user do due to the bug. In here we will also explain if the bug has a traffic affecting, feature blocker, management affecting, test stopper etc. In addition we will need to write if we can work around the bug and if so, to explain in details how to work around it.
Full scenario for reproduction the steps made by the tester – attach the test case from the STD. Here you should also attach all links or relevant files, images, core files and logs.
Remember that many people need to read and understand your bug so you need to give any information that can help them to understand the bug, to reproduce it and to fix it.
Because many people read it, try to write it clearly and simple as you can and don't forget to use the speller (I usually write all bug info in word document, fix all typos and then copy it to the QC/TD/bug tracker system).
No comments:
Post a Comment