Advice for Software Testers from Bug Validation – Krishnaveni
I recently got an opportunity to validate two contests on 99tests.com
This experience was quite refreshing, since it was like a refresher’s course for me to re-learn and re-visit things that I had learnt when I started out as newbie in Software Testing.
Bug Report is a crucial aspect of software testing. For bugs to be of value, effective bug reporting is a must.
Here are the lessons I learnt yet again.
Scope of Testing
First and foremost consider the scope of testing mentioned. Any bugs not coming under the given scope will be deemed invalid.
Bug Logging Guidelines
If the client or the contest owner has stated specific guidelines to log a bug, make sure to go through it before logging any of the bugs. If the tester fails to read them, chances are high that the bugs reported by the tester could lack in key information or bug format the client is expecting to get. Be attentive of what is expected of you.
Before logging a bug, consider if a similar bug has already been raised by the others. Someone may have already reported the bug. Searching first helps to prevent duplicates. To be effective, try multiple synonyms and rephrasing of what the bug might have been called.
By not looking out for duplicates, the tester will lose out on the chance to log another valid bug. The known drawback is redundancy when there are many duplicates; however the impact is higher for a tester when the bug number is limited per tester in a contest.
Bugs rejected for being a duplicate will bring down the credibility of a tester.
Testers should assign the right severity for a bug. Clear understanding should be there to distinguish between a show stopper issue and a high issue.
I observed that many testers do not know this. Bugs like a field not accepting the input or a drop down not populating values are marked as show stoppers. Similarly some UI issues too are termed the same.
Show stopper bugs are those, which prevent the user from further accessing the application owing to an issue. In the examples stated above, the user can still access other areas of the application.
Be clear about what kind of bug it is. Is it a functional, GUI or a technical bug? Incorrect marking of bug types is a sure shot way to have the bug marked as invalid.
In order to accommodate more bugs within the specified testing timeframe, most testers log bugs in huge numbers without concentrating on how they are logging it. In this hurry, they just enter a one liner bug and submit it. They fail to realize that doing this way won’t fetch them any credibility. Being testers, one should never compromise on the quality. With practice, one will be able to learn how to manage the time.
Bug report should be complete inclusive of Bug description (one liner), steps to reproduce, expected results, actual results, screenshot or video and the environment details on which the testing was carried out. If there is a time limit allotted to test, that cannot be an excuse to log incomplete bugs. This shortcut will eventually lead to bugs being marked invalid or rejected owing to lack of details
Quality v/s quantity
Quality of the bugs is most important that the quantity of the bugs. It serves no purpose to just keep filing bugs blindly. Though it may appear that the tester is logging in many bugs, the credibility would definitely come down since the bugs would be lacking in content and quality.
Choice of Browsers
Ensure not to test on out dated or non-compatible browsers. It was surprising to see testers having tested the application on IE 6.
This information is one of the key aspects in a bug report that would aid in reproducing the issue.
Many testers fail to include the same while reporting the bug. This makes it very tedious for the client or the bug validator to figure out in which environment setup the issue occurred.
Bug descriptions are a sneak peak into what the bug is all about. They need to be short, crisp and in a line hinting on what the bug is all about. Inappropriate bug descriptions that don’t convey the right message might not catch the attention of the client or validator.
Effective communication skills with a good proficiency in English are a must.
Before submitting the bug, do a proof reading. Check for spell errors. It is quite pathetic to see that as testers who should be finding the flaws, they themselves are unable to see the flaws in their own work.
Example: Sing in page not working
What the tester here meant to write was “Sign in page is not working”. There is a sea of difference between Sing & Sign. Hence care should be take to avoid spell errors.
Usage of short forms of words
Bugs reports are formal communications that help the client to know the issues in their product or application. So as per e-mail writing etiquette, no short forms of words must be used in a formal communication.
Example: One tester had written, the reset password page is not aval.
The tester had used the short form ‘aval’ for ‘available’. This is not a good practice.
Expecting the clients or validators to do mind reading
Don’t expect the client or validators to put their mind to figure out the entire issue just by logging in a bug with least information.
(a) Section ‘car’ accepts invalid inputs. The missing things in this are where is section car?
which page of section car(if the ‘car’ section is occurring in multiple places)
(b) Field is not accepting input in that form (which form?) How is the client
or stakeholder supposed to figure out which form in the entire application the tester is talking
All about screenshots
- Do not save screenshots in .bmp format since they tend to occupy a very large space. This might irk the client since the screenshots might take a very long time to download.
- When multiple screenshots are included in a word document, it is a good practice to include a one liner description above each image so that it helps the client to understand what that image is about.
- When the tester mentions to refer the screenshot in the bug report, the tester should ensure that the screenshot is attached in the bug. Many a times it is seen that the tester forgets to include the screenshot attachment.
- Supposing a particular functionality works fine in one browser and not in another, it is a good practice to attach screenshots for both: browser where it is working and browser where it is not working.
Do not live with the bug
At times testers might have a tendency to ignore a bug if it is a very very trivial GUI issue. They would be so focused reporting major stuff that this might get missed out.
It is good practice not to miss out such bugs based on their severity.
In the particular application where I was validating the bugs, the logout button did not have a tooltip. The icon was appearing such that the very appearance was like a refresh button. It was a good thought of the tester to log a low GUI defect highlighting the same.
Bug Report Contents
A bug report should essentially contain the proper steps to reproduce, expected result, actual result, environment details and screenshots.
Steps to reproduce should start off with the mention of the URL that was tested. In case the application navigates to a different URL owing to an issue, it is worthy to mention that URL in the bug report.
Avoiding invalid bugs
Before reporting bugs the testers should reproduce it themselves to confirm the same.
Also, when ruling out that the error messages are not fired for an invalid input, the testers should ensure that the form/page is submitted in order to confirm if the issue still exists.
Key characteristic trait for a tester
Learnability is an important characteristic trait for people who wish to better themselves.
If the validators have commented on the bugs with tips or suggestions for improvement, the testers should consider them in a positive stride and use them constructively to improve their skills.
Further links to refer:
- Bug Reporting etiquette from bugzilla: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html