Morning, what are an acceptable time and tasks to analyse a defect as a tester?
Following situation: As our QA teams waits for a new client version and our preparations are quite done we had a look at some tracked defects and double checked them to try to give more input to the devs by analysing the error. In the particular case my QA manager and I spent almost four hours together trying to break down the error (checking usage of application, time spans, data base entries etc.) without finding the cause for the error. An additional hour I spent together with one of our devs to finally break it down by debugging application and database procedures to find out that a SQL-Query could not handle some results in the right way and fails. The thrown error was misleading, as the statement which broke didn't had an own error message definied so the last definied errormessage (still current in the out-parameter) was thrown but had nothing to do with the real error.
After talking with my QA manager about what was the cause at the end we asked ourself how far we should go for analysing. For this current case the time spent was not problematic as we got some time at the moment, but we couldn't see a logical point to stop in times where we have more work to do.
So my questions are:
- What is an acceptable time to spend as a tester for analysing and breaking down a problem?
- Where do you draw the line between the tasks of a tester and a developer by breaking down a defect?