Comments on: Who does the pinpointing? http://thetesteye.com/blog/2009/12/who-does-the-pinpointing/ by rikard edgren, henrik emilsson, martin jansson and friends Fri, 10 Sep 2010 09:30:15 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: Henrik Emilsson http://thetesteye.com/blog/2009/12/who-does-the-pinpointing/comment-page-1/#comment-275 Henrik Emilsson Mon, 04 Jan 2010 00:19:57 +0000 http://thetesteye.com/blog/?p=740#comment-275 Good questions and thoughts Martin! I guess that this depends as you say on the type of product and project that you work with. <br> In my experience, having a very complex environment you don't want to find bugs that will give you two more days of "investigating" or pinpointing. Unless you get paid by the hour of course! :-) And a part of this is that the project is too large for any team spirit to grow, so you end up doing something boring and blame someone else for not doing their job; the same way that "someone else" feels when they are assigned to do the pinpointing. At one time I got in the middle of a trench warfare that lasted for several weeks without anything creative happened at all... I think that the bug was closed as not repro after 6 weeks and no one really cared. <br> Working in semi-complex environments I have come a long way by discussing with the developers on how much information they would like to get. And in many cases they are just fine with a link to the log files, a one-liner error message and the timestamp where the error occurred. Experienced developers knows where to look anyway. Others need more assistance. <br> But as always, isn't this a question for the project manager? Where should the project spend the money? I would suggest discussing this with the project manager and come up with a model that would work in your project. Should we make the product more testable? Or even stable? Should we increase the test team? Would it be good to have a dedicated problem solver in the team? Or just someone that helps the project with pinpointing important problems? How about a whole task force that specializes in investigating? Good questions and thoughts Martin!
I guess that this depends as you say on the type of product and project that you work with.

In my experience, having a very complex environment you don’t want to find bugs that will give you two more days of “investigating” or pinpointing. Unless you get paid by the hour of course! :-) And a part of this is that the project is too large for any team spirit to grow, so you end up doing something boring and blame someone else for not doing their job; the same way that “someone else” feels when they are assigned to do the pinpointing.
At one time I got in the middle of a trench warfare that lasted for several weeks without anything creative happened at all… I think that the bug was closed as not repro after 6 weeks and no one really cared.

Working in semi-complex environments I have come a long way by discussing with the developers on how much information they would like to get. And in many cases they are just fine with a link to the log files, a one-liner error message and the timestamp where the error occurred. Experienced developers knows where to look anyway. Others need more assistance.

But as always, isn’t this a question for the project manager? Where should the project spend the money?
I would suggest discussing this with the project manager and come up with a model that would work in your project. Should we make the product more testable? Or even stable? Should we increase the test team? Would it be good to have a dedicated problem solver in the team? Or just someone that helps the project with pinpointing important problems? How about a whole task force that specializes in investigating?

]]> By: Martin Jansson http://thetesteye.com/blog/2009/12/who-does-the-pinpointing/comment-page-1/#comment-274 Martin Jansson Sun, 03 Jan 2010 19:41:20 +0000 http://thetesteye.com/blog/?p=740#comment-274 I really like Michael's article as well. I agree fully that finding cheap bugs makes this even more critical. I've not seen this as an issue in smaller organsations, it is usually handled one way or the other without getting into the spotlight. I think this is more common in larger organisations where information exchange is harder and more complex. If there are several layers to the test organisation it becomes even more complex. Either way, I think this is very underestimated in project planning and test planning. I really like Michael’s article as well. I agree fully that finding cheap bugs makes this even more critical.

I’ve not seen this as an issue in smaller organsations, it is usually handled one way or the other without getting into the spotlight.

I think this is more common in larger organisations where information exchange is harder and more complex. If there are several layers to the test organisation it becomes even more complex.

Either way, I think this is very underestimated in project planning and test planning.

]]> By: Torbjörn Ryber http://thetesteye.com/blog/2009/12/who-does-the-pinpointing/comment-page-1/#comment-273 Torbjörn Ryber Sun, 03 Jan 2010 18:11:32 +0000 http://thetesteye.com/blog/?p=740#comment-273 I recently read Michael Bolton's blog about why testing takes so long http://www.developsense.com/blog/archive/2009_11_01_archive.html I am in a situation now where we find and analyse too many simple bugs so that more advanced testing is severly limited. So my problem is even bigger than just pinpointing - it is also about not enough developer testing. At work - we need to take this discussion in january together with pinpointing issues. We do a lot today because we can and bugs get fixed faster but at the same time we undermine our possibilities of doing a good job. I do not mind helping out as much as I can but it has a price - that is what our discussion is going to be about. I recently read Michael Bolton’s blog about why testing takes so long http://www.developsense.com/blog/archive/2009_11_01_archive.html

I am in a situation now where we find and analyse too many simple bugs so that more advanced testing is severly limited. So my problem is even bigger than just pinpointing – it is also about not enough developer testing.

At work – we need to take this discussion in january together with pinpointing issues. We do a lot today because we can and bugs get fixed faster but at the same time we undermine our possibilities of doing a good job. I do not mind helping out as much as I can but it has a price – that is what our discussion is going to be about.

]]> By: Rikard Edgren http://thetesteye.com/blog/2009/12/who-does-the-pinpointing/comment-page-1/#comment-271 Rikard Edgren Sun, 03 Jan 2010 17:53:59 +0000 http://thetesteye.com/blog/?p=740#comment-271 This is a very interesting area, where I think it's almost impossible to be at the exact right level. It's not only the time issue, it is also a question of learning, that happening when pinpointing, and can be very useful knowledge, both for testers and developers. One answer to the "Who" question could be "the group that has most available time" or rather "the group that is the least over-booked". When forming team size, it could be argued "with one more tester we have resources to do more of the pinpointing." When deciding scope, it can be good to put more effort on logging, in order to save time when those tricky bugs appear. The pinpointing issue can also be fuel for conflicts, e.g. accusations that testers don't put enough effort on the right information in the bug reports. If you have a situation where testers don't like to work with certain features, due to too much extra-investigations for every bug, then you have a problem where resolving the pinpointing ownerships can be part of the solution. This is a very interesting area, where I think it’s almost impossible to be at the exact right level. It’s not only the time issue, it is also a question of learning, that happening when pinpointing, and can be very useful knowledge, both for testers and developers.
One answer to the “Who” question could be “the group that has most available time” or rather “the group that is the least over-booked”.
When forming team size, it could be argued “with one more tester we have resources to do more of the pinpointing.”
When deciding scope, it can be good to put more effort on logging, in order to save time when those tricky bugs appear.

The pinpointing issue can also be fuel for conflicts, e.g. accusations that testers don’t put enough effort on the right information in the bug reports.
If you have a situation where testers don’t like to work with certain features, due to too much extra-investigations for every bug, then you have a problem where resolving the pinpointing ownerships can be part of the solution.

]]>