Don't know what the scope of the potential position where this question came up...but could the question be boiled down to something as simple as the interviewer trying get you to identify how you break down and log defects?
Breaking this one down. I think the interviewer could be looking at a couple of things:
1. Critical thinking skills
2. Defect logging skills
"The single biggest problem in communication is the illusion that it has taken place."
-George Bernard Shaw, Irish playwright and Nobel Prize winner, 1856-1950
when you have stack trace, it should be taken as critical as it is easily viewable to the end user, just copy the stack trace and paste it along with as how to reproduce it and what data brings back that error to life.
The above question asked is converned with developer, who finds 3 no of causes(Coding error) to have functional/appln defect.
As a tester or QA person we are not anyways going to see what is the cause for defect.
[ QUOTE ]
If there are 3-4 code errors (Stack trace) and all this adds up to show a single functional error. How do you categorize and report the individual code errors?
[/ QUOTE ]
I talk with a developer on the team and ask them how to most effectively report the issue(s). Is there truly only one problem here - or are there three problems? or more?!?!?
Talking with a developer, who will ultimately have to go behind you in the bug tracking system, will help the team discover the true status of the code. Providing the team with only one bug report - including recreation steps and that stack trace may be enough.
Maybe there should be four reports? 1 for each individual error and 1 more for the combined outcome.
Each development team I've worked with would report these in different ways depending on their internal knowledge of the code. So my answer wouldn't really be an answer at all... just conjecture from my past, and hopefully insight into how I would approach the issue at hand.
This three minute conversation with the development team may save hours of agony when they finally get around to working on the issue... and the interviewer is probably much more interested in how you interact with the team than just the numeric answer of one, two, three or four reports. [img]/images/graemlins/wink.gif[/img]