I'm new here and very happy to find this site.
I just want some opinion from the seniors here...
In an interview if they give us a new website to test and ask us to write a bug report,in what format should someone write a bug?..
i read in this forum,written by Swetkamal to follow this following format.
There is no standard format but normally it should be divided into twos
a) The Header : Should describe the Project / Module details and the overall summary of the defect (in terms of number)
b) The Description: should Talk of defect. It should include the fields like
1. Sl No
2. Defect ID
3. Test Case ID
4. Defect Description
7. Detected By
8. reproducible or Not
9. Defect Identified Date
10. Status (Open, Close etc)
11. If Closed (Date)
if i follow this what will i fill in for sl no,defect id,test case id.
2) if i find a bug,which is actually feature what should i do.
If I were to ask this question of a perspective hire, I'm not concerned with format at all. I am much more concerned with content. Did the tester capture everything he or she needed to in order for the developer to deal with the defect?
Too often, I have seen testers who find a defect and enter the defect with such cryptic descriptions as "on screen X, the YYY field is not working correctly."
What I want to know is: will the tester give me complete details? What was the input? How did you get there? What is the nature of the failure? - not just "it doesn't work". What should it have done instead? What is the requirement that you are testing - I see that this one is missing in your list. I don't have a single test case per requirement - I often test multiple requirements in a single script.
If you are worried about the format, you are too close to the problem and losing sight of the big picture - have I given enough information for the developer to track down and erradicate the defect?
I agree with Darrel, in an interview setting use a format that you are comfortable with and concentrate on what really matters - providing enough information for the bug to be reviewed and corrected by the developers.
Regarding Q2 (and the title of the thread), how would you KNOW something you reported as a bug was actually was a feature, unless (in this case) the interviewer told you? Or was the interview question "what would you do if the bug were a feature?"
What should you do? Well, that depends on the "feature." If you have reason to believe that the "feature" will be hugely unpopular with the customer base, you might argue for it to be changed. Otherwise, you say "thank you, Mr (or Ms) Product Manager. I appreciate your telling me that." And cancel the defect record.
I will add my Subjective details, that don't contradict with other posts:
When I give such an exercise I want only two fields: description (full) and summary (short).
Regarding feature VS bug - if you don't have development documents and don't know the business and quality goals (and you don't in your case) you can't guess feature VS bug. Anything you find is issue. You should describe issue of having or not having that feature instead of describing why it is a bad feature or a good feature to add. Also - avoid subjective issues.