我发现 Jerry Weinberg 在“完美软件：以及其他关于测试的幻想”中关于精确定位的评论真的很有帮助。（我的副本在工作，所以这是凭记忆）。

Jerry 评论说，有时由程序员负责确定错误的确切位置，有时由测试人员负责。以我的经验，当不清楚谁应该做什么时，最麻烦的就会发生，尤其是当这意味着一场关于谁应该将团队的预算花在这项工作上的管理斗争时。

我认为很难想出一个适用于单个测试人员的启发式方法，因为决定精确定位的责任应该在哪里并不是单个测试人员应该做出的决定：这是一个管理决策。精确定位所花费的时间可能非常不可预测，并且可能需要相当长的时间。

（是的，如果您的团队有权自行决定在哪里分配资源，这可能是一个团队决定。在我目前的环境中，这实际上还不是问题——在我看来，这是因为我们没有单独的编程和测试团队，我们都在同一个房间里工作，我们密切合作以追踪棘手的错误。）

如果我确实必须讨论精确定位的责任，我想找一些程序员、一些测试人员以及负责资源分配的任何人（PM、产品负责人、开发/测试团队经理），并考虑以下因素：

1. 产品的可测试性：追踪错误有多容易——您是否有良好的日志记录、对测试环境的足够控制以控制某些变量、是否能够轻松设置测试数据？
2. 程序员/测试员的比例：如果你有一个测试员到六个程序员，并且他们把所有的测试时间都花在了查明错误上，他们就不会发现很多新的错误。
3. 程序员和测试人员的相对技能水平（你的编程人员流动率高，测试团队相对有经验吗？反之亦然？）
4. 编程和测试团队对整个系统的相对理解水平。（程序员是否只在他们自己的组件上工作，并且很少接触与之交互的系统？测试人员呢？）
5. 测试人员和程序员之间的反馈循环有多长？您能否直接交谈以更好地了解双方都需要哪些信息？测试人员提出问题和程序员解决问题之间平均需要多长时间？到那时，程序员是否脱离了上下文？是测试员吗？

在这篇关于 pinpointing 的博客文章中也有一些非常深思熟虑的讨论，其中提到了上述一些因素等等。

我试图遵循的一般规则是“尊重每个人的时间”——这是我从伟大的书“软件测试中的经验教训”中记得的教训之一。当我建议我的团队成员是否继续调查时，以及在协商我在调试方面为开发团队提供多少帮助时，我会想到这一点。

我在这里没有提到的其他东西是测试人员的经验。
我现在的工作已经超过 10 年了，我将比我们一年前雇用的人更好地理解应用程序、日志文件和数据库。
我进一步挖掘和提供更多信息的能力只是我时间的一个功能。新手可能不知道调试选项或日志文件或我所做的其他事情。还有其他比我更熟练和更有经验的测试人员，他们的错误报告会比我的好。

我会争辩说，当你思考这个问题时，正是时候。

但是等一下，如果可以的话，把它们带过来和他们一起检查——你已经在调试器中得到了它——如果他们在大楼里，如果你们俩花 10 块钱，他们会理解并更重视这个错误一起调试。随意为它提出一个问题，但最好尽可能面对面地进行沟通。

我真正争论的是结对编程/结对测试。一旦确定有问题，请与他们一起解决。