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?

2 Answers 2


It depends.

I saw acceptable time/effort ranging from 0 (outsourced testing to almost un trained testers) to infinity and beyond (combined engineering team with engineers that know their way through the code and product).

YOUR answer will vary according to (just throwing some ideas):

  • Your skills and knowledge e.g. how familiar are you with the product, code and coding

  • Urgency of the bug compared to other tasks that you or your team have, how busy the developers are, the company/division/team work load today and in the coming hours/days/weeks

  • What is expected by your manager, manager's manager and so on

  • Do you want to do it ? for example as an example to others that "testers can code"

All of the above means that even for you there is no single correct answer, usually that's what "bug meetings" (or whatever they are called in your company) are for.


Timebox it and afterwards evaluate. I would say time-box one hour and then see how probable it is the tester will find the steps to reproduce the issue.

Often its easier for developers to reproduce the issue, since they understand the code for that part. And they are more proficient in code-debuging.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.