If you at sometime in your life lived your life as a Quality Analyst, you will definitely understand what does this means and what am I going to share in this piece of blog.
Lets start with the problem statement as in my all blogs, I used to share why and how it come up in my mind the idea of writing this blog ,similarly in this post , I will start with the general trend.
Yeah, generally we have very less options when this question come up to a tester while sending a test report to some developer or team. It happens to me often, when a file a bug in some bug tracking tool like JIRA, and the worst part is to convince some other person for the bug I have reported.
For example, there is a web site which takes load of data and while executing tests ,general user interface testing , I found an issue which is halting me to log into the system. So the problem statement is quite complicated , I understand, but is very common. Take this website as a e-commerce website which takes registration of users all over the world, stores cart , history , product syncing , etc from the database .
I have seen this happening to many websites which are very popular and is widely accepted in the market. What shall a tester will do , who is testing this website ? Lets see:
1. Observation :
Log in was 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! Web site is working perfectly fine for me .
Guess what ? now what a tester will do in such situation …He has to reproduce the issue .
What he should do ?
Root Cause Analysis
He should write specifically ,while writing bug that
- At what circumstances he got the issue ,
- Issue could be because of Traffic of data,
- Server communication of connection,
- Infra-structure issue,
- Data base 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:
1. Description of bug.
2. Title of bug.
3. Environments on which the bug has seen.
4. Virtual machine used like Windows , Linux, etc
5. Database used like postgres , DB2 , MainFrames , Oracle ,etc.
6. Steps involved to get it fix.
7. Time , in this case , as the reason for this could be the availability of users. For example, if its an Indian website then the time of maximum user who use the website will differ from the United Sates user using the website. Also during SALE time maximum user use to look into the products and that can cause crash in the websites if, it exceeds the maximum limit.
Also with the best practices, we need to adopt innovative approaches like :
1. 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.
2. Use HTTP Tracker Tool (FIREBUG, FIDLER, HTTPFOX) to view the response of request.
3. Use some light weight screen recording /capturing tool to capture execution flow of complex test cases and attach the video file to the Defect.
Build a good relationship with development team in handling this type of situations 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.
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 🙂