让我们想象一下这种常见情况:测试人员会为开发人员解决一个问题,提供重现步骤,屏幕截图和其他详细信息(如果有)。然后,开发人员认为问题不够详细,要求测试人员花更多时间研究可再现问题的条件,或者添加更多关于问题何时发生的观察和注释。在某些情况下,这种请求确实有效-添加更多详细信息确实有助于进一步缩小问题所在,但我经常看到开发人员不愿意花费额外的调试时间,即使这对于他或她来说更容易而不是让测试人员确定会发生什么。有时,这是因为该开发人员对测试人员的时间重视程度不如测试人员的时间重视(这对团队而言是不健康的事情)。在这种情况下,开发人员和测试人员之间会发生冲突。

这种情况是不可避免的,因为双方都在调试和查明问题的中间临时共享状态下进行操作。但是,避免或解决此类冲突并使团队之间的关系保持健康高效的一般方法是什么?

评论

我认为解决此问题的一种好方法是记录您为达到此状态所采取的步骤。我发现最好的方法是使用屏幕共享记录来演示如何正确遇到该错误。当然,还应包括尽可能多的详细信息,例如浏览器,操作系统等。您还可以使用一个模板,每次记录错误时都在其中填写表格,以确保报告的一致性。

@alecxe-我不确定是否有用于提问的徽章,但应该是,您应得的。

根本没有一般的决定方法。有时是用户的防病毒软件。

“有时候,这是因为该开发人员对测试人员的时间重视程度不如他或她对开发人员时间的重视程度(在团队中这是不健康的事情)” Cough。您是说像测试员那样,在99%的案件中所获得的报酬比开发人员要少?将更多的工作量放在小时成本较低的方面,并腾出更多的昂贵资源来执行低薪资源无法完成的工作,这完全是理智。就薪资而言,人们并不完全平等。

这不是开发人员的选择。浪费客户资源是否合乎道德?是否因为不想将更多的工作投入到恰好具有这项工作的其他低薪资产上,是否合乎道德?我会争辩说,一个开发人员在浪费时间在进行欺诈。测试人员正是在那里进行此类工作的。关于浪费金钱和拒绝让受雇从事特定工作的人干任何事都没有礼貌。

#1 楼

如果要求听起来合理(包括考虑其他优先事项),我将花更多时间进行研究。

如果不合理,我会回答“对不起,这是我能做到的最好的事情”,如果我有礼貌地拒绝花费更多时间进行研究对开发人员来说是不够的,我将要求我的经理做出决定。我还要向经理提一下:


如果开发人员可以更好地进行更深入的研究(如果是这样的话),
如果所研究的代码处于混乱状态,并且存在很可能在对错误进行调查之前将其进行更改(使错误报告过时且无意义)
当前QA管道中的其他任何错误都与相邻代码发生接触(如果我知道的话),因此可能需要其他开发人员参与
/>其他任何相关信息也可以使我的经理更好地做出明智的决定。

我的经理会告诉我:


我需要花费与我的其他任务(我将与开发人员交流,以便开发人员可以决定不等待)相比,可以花更多的时间并分配优先级
,或者确定我已经花了足够的时间,并与开发人员的经理进行了交谈。

同行之间的分歧正是我们拥有经理的原因。另外,开发人员的经理想知道这种将工作从开发人员转移到测试人员的请求是否是特定开发人员的模式。

质量是一项团队运动。团队中的每个成员都必须与时俱进,如果不是这种情况,管理人员会在这里解决分歧。

评论


“调查”并不意味着“找出错误发生的原因,以便我们开发人员可以对其进行修复”,而是意味着“我们开发人员无法对其进行复制,因此我们无法对其进行处理,请记录下可以更好地进行复制的步骤,因为错误报告不足以使我们对此采取行动”。如果您报告错误,则应将其欠开发商,以向他们显示缺陷,否则他们将根本无法解决问题。

– Beanluc
17年9月14日在16:28

@Beanluc-您听起来像是一名开发人员,而且是一个认真的人。您可能会惊讶于某些(除您之外)开发人员可能会尝试将更多工作推向质量检查人员(“需要进行更多调查”),以便他们可以将更多时间花在诸如在工作时间观看工作站足球比赛之类的事情上。我已经看到了它的发生。

– Peter M.-代表莫妮卡(Monica)
17年9月14日在16:58

#2 楼

这取决于。

正如Joe Strazzere解释的那样,这是开发人员和测试人员之间讨论的问题。问题是在讨论中要考虑哪些因素。我认为Danny R. Faught在“如何使您的Bug寂寞:错误隔离的技巧”中很好地解释了这一点。


在错误隔离和
之间没有明确的界线。报告测试人员进行的操作以及程序员进行的调试操作。在大多数组织中,测试人员有足够的空间
进行更多工作以隔离错误。另一方面,
也可能有理由让测试人员报告他们看到的第一个症状,然后继续进行下去。

这里有一些有利于拥有测试人员的因素
花了很大的力气来隔离他们报告的bug:


测试人员可能比程序员更有动力,表明该bug具有真正的影响,应予以修复。 />因为与程序员相比,他们在错误报告上花费的时间更多,所以与隔离程序相比,测试人员在隔离错误方面可能会更好。 />测试人员可能比程序员拥有更多的资源,例如人员和实验室设备。

但是,也有一些因素表明,最好的方法是
错误隔离对程序员的重要性:


测试人员可能没有很高的技能或经验,所以他们可能不擅长ug隔离。
测试人员可能会花很大的精力来隔离一个错误,该错误原来被认为是修复的优先级较低。
测试资源可能比开发资源更受限制。
它可能会更有生产力使用代码知识来放大问题。
让测试人员进行重大的错误隔离会使他们有些不可预测的项目进度更加流畅,因为很难做到
预测将发现多少个错误,以及表征它们的难易程度
。当然,如果我们
将工作转移给他们,那么程序员也会遇到同样的问题。



评论


+1仅代表第二个列表的第二点:测试人员可能会花费大量精力来隔离一个错误,事实证明该错误的修复优先级较低。尤其是如果我们已经将工作放到使该错误不相关的下一个迭代中,或者偶然地修复了该错误,那么质量检查人员将无从得知。

– sq33G
17年9月13日在10:08

@ sq33G完全正确。这就是为什么我提倡让经理尽早参与我的回答。

– Peter M.-代表莫妮卡(Monica)
17年9月13日在13:48

@ sq33G:同时,通常,只有在调查后才能了解错误的确切范围。一百万分之一的触发错误的机会实际上可能揭示了一个安全问题,该问题允许转储整个数据库(Equifax!)。在不完全了解该错误之前,无法对其严重性进行评估。

– Matthieu M.
17年9月14日14:23在

@JoeStrazzere:对于您拼写错误的名字,我深表歉意。

– dzieci
17年17月17日上午11:35

@dzieciou-不用担心。我看得更糟!

–乔·斯特拉泽(Joe Strazzere)
17年11月17日在17:08

#3 楼

我工作过的许多公司都共享一个策略...
...该策略是:

测试人员可以自由地与开发人员进行协商,同时尝试刻画,隔离或重现异常行为。
一旦测试人员可以记录忠实地重新创建行为所必需的步骤,开发人员就应该能够从那里获取它。
开发人员也可以自由地与测试人员进行协商,以澄清和协助重新创建行为。或任何其他原因。
其背后的逻辑非常简单:

开发人员应该更好地了解程序的哪一部分可能负责观察到的行为。
开发人员通常可以使用调试器来浏览可疑代码,同时观察调用结果和中间值。
在调试不可行的系统中,开发人员可以修改代码,插入其他调试信息输出或记录代码中的可疑区域。测试人员通常不能做同样的事情。

因此,让开发人员负责代码修复通常更为有效。

评论


同意,但开发人员可以选择要求测试人员针对特定内容进行测试,例如“如果……或这两个经过修改的版本中的哪一个行为不同……也会发生吗”,尤其是当该错误需要一段时间才能重现时。

–kaay
17年9月13日在10:47

开发人员还应具有与测试人员进行协商的自由。测试人员通常更擅长于复制错误,尤其是在涉及时间安排或难以描述的动作的情况下,它可以真正帮助开发人员亲眼看到如何复制他的错误。

–巴特·范·恩根·舍瑙(Bart van Ingen Schenau)
19年7月25日在8:44

@BartvanIngenSchenau-好了!

–MrWonderful
19年7月25日在8:48

#4 楼


但是,避免或解决此类冲突的一般方法是什么?
保持团队之间的关系健康和富有成效?


两者质量检查管理人员和开发管理人员必须就错误报告的基本规则达成共识。

在某些商店中,在错误报告足以移交给开发人员进行修复之前,需要更多详细信息。对于经验不足的开发人员或将维护/开发外包的情况,可能会发生这种情况。

其他商店要求的细节较少。

有些商店喜欢打电话给开发人员/测试人员亲自演示该错误(在更方便的办公桌上看),并让开发人员写下他认为需要的任何注释。

总是上下文和公司特定。

#5 楼

以我自己的经验,开发人员和测试人员之间的良好个人关系有助于解决此问题。如果测试人员和开发人员在公司环境下足够友好,那么谈判将永远不会被视为谈判。双方都认为,这应该通过团队合作来完成,并且成功与失败将在双方之间共享。

总是存在一些错误报告和修复的规则和程序,但是如果没有奉献精神,适当的合作冲突可能会继续下去!

#6 楼

对我来说,谁负责取决于您拥有什么样的团队。

如果您有传统团队,则必须达成协议,详细说明测试人员将做什么以及开发人员将做什么。

如果您在Scrum团队中工作,漏洞是团队的责任。这意味着开发人员和测试人员。根据您的团队喜欢工作的方式,测试人员将或多或少地努力描述和/或隔离问题。

就个人而言,在这种情况下,我宁愿放弃自己的复制步骤,然后与开发人员坐在一起向他们展示问题的根源以及如何精确地解决问题。根据问题,然后我要么继续尝试隔离它,要么开发人员开始尝试对其进行修复。

如果事情必须通过票务系统进行,而测试人员和开发人员之间没有任何其他交互,则可能会浪费大量时间进行ping-poning,这与敏捷和灵活的整个观点相悖。如果对需求的解释(用户故事或规范)有所不同,则可以进行简短的讨论,然后找出答案或找到可以的人。只需几分钟,而不是几天。

#7 楼

我个人认为,尝试收集有关该错误的尽可能多的信息以使有问题的开发人员可以修复该错误是一个好习惯-是的...我只是说了明显的话,但请听我说。我认为向开发人员提供屏幕截图,堆栈跟踪,日志,重新创建步骤,常规信息(是浏览器还是特定于操作系统?)以及尽可能多的“证据”是我经验中最好的方法。不能由汽车的测试驾驶员确定奇怪的发动机噪音来自何处,但是您可以告诉工程师或机械师,它只会在转速为6000 RPM和X速度下发生,而向左转时,赶上我的漂流(双关语是故意的)。简而言之,这不是您的工作,而是指出它到底在哪里中断,但是您可以在开发人员自己进行故障排除时帮助开发人员查明。

#8 楼


作为经验,我们遵循的原则是提供足够的信息和
屏幕快照,以重现问题,而无需在开发人员部分承担任何责任。


有时我们被要求提供其他信息,以提供视频或在质量检查环境中实时向开发人员/团队展示,但系统内部状态仅需由开发人员扣除。