在将问题移交给开发人员之前，测试人员如何决定要进行多少调试/调查？

#1 楼

我发现杰里·温伯格（Jerry Weinberg）在“ Perfect Software：以及其他有关测试的幻想”中关于精确定位的评论确实很有帮助。 （我的副本在起作用，所以这是从内存中获取的。）Jerry指出，查明错误的确切位置的责任有时由程序员，有时由测试人员负责。以我的经验，最大的麻烦发生在不清楚应该由谁来做的时候，特别是当这意味着在管理上要争夺谁应该将团队的预算用于这项工作时。
很难找到一种对每个测试人员都适用的启发式方法，因为确定精确定位的责任并不在于单个测试人员应该做出的决定：这是一项管理决策。精确定位所花费的时间可能是非常不可预测的，并且可能要花费相当长的时间。

（是的，如果您的团队有权决定他们在哪里分配资源，在我当前的环境中，这实际上还不是问题，在我看来，这是因为我们没有独立的编程和测试团队，我们都在同一房间工作，并且我们紧密合作一起追踪棘手的错误。）

如果我确实不得不讨论精确定位的责任，我想找一些程序员，一些测试人员以及负责资源分配的人（PM，产品所有者，开发人员/测试团队经理），并考虑以下因素：产品的可测试性：查找错误有多容易-您是否拥有良好的日志记录，是否足够控制您的测试环境以控制一些变量，是否能够轻松设置测试数据？
prog的比率rammers / testers：如果您有一个测试员到六个程序员，并且他们花费所有的测试时间来确定错误，那么他们就不会发现很多新的错误。
程序员和测试人员的相对技能水平（您在编程方面有很高的流失率，还是有一支相对经验丰富的测试团队？反之亦然？）
在编程和测试团队中对整个系统的相对理解水平。 （程序员只在自己的组件上工作，而很少接触与之交互的系统吗？测试人员呢？）
测试人员和程序员之间的反馈回路需要多长时间？您能否直接交谈以加深对双方都需要哪些信息的了解？测试人员提出问题与程序员选择解决问题之间的平均时间是多长时间？到那时程序员是否脱离上下文了？是测试人员吗？

在此博客文章上还进行了一些非常细心的关于精确定位的讨论，其中提到了以上以及更多因素。

#2 楼

我尝试遵循的一般规则是“尊重每个人的时间”，这是我从《 SW测试中的经验教训》一书中记得的课程之一。当我建议我的团队成员是否继续调查，以及在协商我对开发团队提供的调试方面的帮助时，就会想到这一点。

#3 楼

我这里还没有提到的是测试人员的经验。
我已经从事了10年以上的工作，与我们相比，我对应用程序，日志文件和数据库的了解要好得多。 1年前被聘用。
我进一步挖掘并提供更多信息的能力只是我所处时间的功能。新手可能不知道调试选项或日志文件或我做的其他事情。还有其他测试人员比我更熟练和经验丰富，他们的错误报告将比我的更好。

#4 楼

我会争辩说，当您在考虑这个问题时，正是合适的时机。

但是，如果可以的话，请带他们过来，并与他们一起经历-您已经接受调试器-如果他们在大楼里，如果你们俩花10分钟一起调试，他们将更加了解和重视该错误。随时为此提出一个问题，但是最好在可能的情况下进行面对面的交流。

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

#5 楼

我不确定这里是否可以应用一种启发式方法。我要做的一些事情（假设这不是“打开此表单并获得访问冲突”之类的超显而易见的东西）：


我每次都能实现吗？
我是否简化了使问题最小化的操作顺序？
我是否排除了错误的配置或损坏的数据？
应用程序日志是否提供了任何有用的信息？
是否可以增加可用的日志记录以获取更多信息？
是否有人报告了此问题？ （这通常是第一个检查-如果已经有错误报告，则无需花时间确定以上所有内容，除非我认为现有的错误报告未提供足够的信息）。
有多重要它到系统？ （特别是当我测试正在进行的开发工作时，我只是要求开发人员看看是否有时间，如果他们没有时间，而不是提供详细的错误报告，那么就不要紧，而是保存详细的错误报告以供发布软件）
我需要花费多少时间来跟踪此问题？ （始终交叉引用该问题的严重性）
开发人员需要花费多少时间来跟踪该问题？ （同样，交叉引用的重要性）
用户遇到此问题的可能性有多大？ （我承认，这通常是部分受过教育的猜测）
我需要包括屏幕截图吗？
我需要包括显示事件序列的视频吗？
在软件的这一部分中进行积极的开发（如果某些事情受到正在进行的开发的影响，则错误通常会消失，而无需采取任何进一步的措施）

通常，我尝试首先进行分类，以寻找一致性，严肃性和影响力。在这三个类别中排名最高的事物（例如，一种具有税收配置X的特定产品总是错误地计算了退税）将比您不得不左手跳三下的bug会得到更详细的信息。和...

要记住的一件事是，除非您的组织强制实施“隔离墙”，否则测试人员只需询问开发人员他们需要什么信息来发现问题就会大为不同。

每个错误的“足够”的信息各不相同：如果我可以使开发人员指出问题的根源，那就太好了，但是如果我不能，那么我将给出我需要做的事情来重现它并用我的手指。

#6 楼

是的，好的问题。对这个问题的答案取决于多个因素。没有黄金法则可以说这是所需的调查级别。我将分享我在此方面的经验


作为测试人员，您是否同意所提供的步骤，所提供的详细信息足以使您的同行进行复制/验证，并同意是否存在错误。这更是个人的满足。如果细节不完整，它将在实际到达根本原因/错误再现步骤之前再次在开发人员和步骤之间进行往返通信
如果测试人员打开的错误数量已关闭表示为“不可复制”，“不是错误/设计使然”，“环境问题”，那么它肯定表示质量检查人员会提供“更多信息”，而不会错过发布到生产环境中的“有效缺陷”
如果错误明确地映射到功能规格以弥补缺少的功能，清除重复步骤，快照是否不一致，调试模式下的日志文件条目，部署应用程序的环境将对开发人员调查问题有帮助。最终目标是识别/调查问题以识别问题。如果您提供的步骤足够使开发人员着手进行repro和代码修复，那么这将节省调查和确认是否是bug的时间
您观察到某些行为与测试用例的预期结果不符
检查问题是否持续发生，分类是否为设计问题/需求问题/环境问题
根据它掉落的桶进行进一步调查
示例1-如果environmetal问题，您需要检查行为是否有任何更改的32位/ 62位，此行为是否更改取决于系统中软件安装的设置
示例2-需求问题-验证此特定情况下需求的期望值（如果未明确指出任何行为）。根据其他方案，如果您可以得出预期的结果与实际的情况，那应该是记录缺陷的好地方

希望这可以提供一些清晰度和方向。

#7 楼

在“在哪里画线？”部分中关于“如何使错误变得孤独：错误隔离的技巧”的作者说：


错误隔离与报告测试人员所做的没有明确的分界线以及程序员
所做的调试。


作者列出：隔离他们报告的错误，以及
可能表明最好将大部分错误隔离的重担放在程序员身上的因素

作为测试人员，我特别同意“测试人员可能比程序员拥有更多的资源，例如人员和实验室设备”。在我们的项目中，开发人员通常在组件级别上进行更多工作。同时，测试人员倾向于更多地了解我们的系统与其他系统的集成点以及操作环境，因为他们更多地参与了端到端测试。

#8 楼

在不了解您，您的组织和项目的情况下，局外人很难提出一种您认为足够好的启发式方法。但是，如果您愿意以诚实，开放的态度与有关各方紧密合作，并且愿意挑战所有场所，那么您最终可能会得出一个令您满意的结论。

#9 楼

考虑一下您在更大范围内的角色。您正在尝试尽快将最好的软件交付用户。

最重要的是提供足够的信息，程序员可以重现该问题，并可以确保已解决该问题。

发现并记录错误时，您就是该问题的专家。您可能比其他人处于更好的位置，以收集有关该错误的有用信息。该信息对于确定谁应该对该错误进行处理与其他错误相比有多么紧急非常有用。 （我过去曾在Microsoft Visual Studio上工作，有2000多名工程师。将错误发送给合适的人通常很难！）

某些类型的错误会从某些类型的信息中受益。例如，我想要任何崩溃报告的调用堆栈。

在许多团队中，程序员的时间比测试人员的时间更宝贵。熟练的程序员可能比熟练的测试人员更难雇用。与增加测试人员的数量相比，增加程序员的数量会带来更多的负面影响。程序员通常比测试人员获得更高的报酬。由于这些原因，如果您可以花费1个小时的时间来节省程序员的1个小时的时间，那么这对团队和客户都是有益的。就是说，如果您要收集程序员不需要的信息，那将是浪费时间。区别在于上下文。有了经验，您会更好地知道何时该停止。

因为这都是与上下文相关的，请寻求反馈。向友好的程序员显示错误报告，并询问他们是否希望获得更多信息，或者是否不需要提供任何信息。请记住，程序员通常偏向于节省自己的时间，而不必花很多钱，所以不要把自己的话当成福音。

#10 楼

测试人员最关心的问题应该是“我是否找到并编写了足够的文字，以便开发人员可以从此处拾取并成功调试并解决问题？”

确定特定的停止点要求您知道开发人员的能力以及您对商店的总体期望。

一些开发人员/公司要想获得成功，就需要您提供更多细节。其他人的需求要少得多。

当开发人员是新手，承包商或在其他地方时，我们可能需要提供更多详细信息。另一方面，当开发人员已经待了很长时间，并且也许坐在高喊距离之内时，所需的详细信息就少得多。

错误报告与沟通有关。与所有交流一样，您需要针对受众定制演示文稿。与所有沟通一样，您的反馈循环将告诉您是否成功。如果没有，则需要下次修改演示文稿。