Dude , its not a ‘bug’ , its a ‘feature’ !!
- khyati sehgal
- May 25, 2014
- 3 min read
If you have a product mindset and working with an Agile team, you will definitely feel connected with the problem statement I am going to share today.
Yeah, generally we have very few options when this question comes up to a tester while sending a test report to the team. It happens to me often, when a file a bug in some bug tracking tools like JIRA, Microsoft Test Manager, etc, and the worst part is to convince some other person for the bug that I have reported.
For instance,
there is a web site that takes a load of data and while executing tests,
general user interface testing, I found an issue that is halting me to log into the system.
So the problem statement is quite complicated, I understand, but it is very common.
Take this website as an e-commerce website that takes registration of users all over the world, stores carts, history, product syncing, and what not from the database.
I have seen this happening to many websites that are very popular and are widely accepted in the market. What shall a tester do, who is testing this website?
Let’s see:
1. Observation :
Log in is not working properly.
2. Bug filed:
As a user, I am not able to log into the system.
3. Noise created :
What the er..r.. its a blocker, how can you test now? Its a severe issue, and shall be fixed ASAP.. else we will be in a trap!
This website can not be launched, as the bug is coming very intermittently.
ARE YOU KIDDING ME ?? THIS IS NOT A BUG! The web site is working perfectly fine for me.
Guess what? now, what a tester will do in such a situation ? He has to reproduce the issue.
What he should do?
Root Cause Analysis
He should write all the specification in while logging a bug that can be
At what circumstances he got the issue,
The issue could be because of the Traffic of data,
Server communication of connection,
Infra-structure issue,
Database connection, etc.
So the question is, what is the good practice?
The best would be if tester while writing the bug shall write all the factors along with the steps he performed, like this:
Description of bug.
Title of bug.
Environments on which the bug has seen.
Virtual machine used like Windows, Linux, etc
The database used like Postgres, DB2, MainFrames, Oracle,etc.
Steps involved to get it to fix.
Time, in this case, as the reason for this, could be the availability of users.
Understanding by example
if its an Indian website then the time of maximum users who uses the website will differ from the United States user using the website. Also during SALE time maximum user use to look into the products and that can cause a crash in the websites if, it exceeds the maximum limit.
Also with the best practices, we need to adopt innovative approaches like :
Get access to the log file, copy and paste the request and response of error into a text file and attach it to the defect.
Use HTTP Tracker Tool (FIREBUG, FIDLER, HTTPFOX) to view the response of the request.
Use some lightweight screen recording /capturing tool to capture the execution flow of complex test cases and attach the video file to the Defect.
Back to the basics?
Build a good relationship with the development team in handling this type of situation and work as one team.
It is always better to find a non-reproducible bug than to miss a bug altogether.
If the bug is documented it is very useful if another team member also triggers it during their testing.
You should not be embarrassed about non-reproducible bugs.
Think of the outcome, we are here for a Goal which is successful delivery. As one team, we shall always look for the solution so that we can remove blockers together.
Infrastructure
Now we have cloud-based set up almost everywhere, we shall look for the no-so-cost hitting solution to the existing project. So that we can reach the optimal solution.
That’s how you can lessen down your burden of reproducing the bug, and also developer while fixing the same bug will get an idea of the issue very early.
Very truly said, Time is Money, and hence we can save Money 🙂
Comments