#1 楼
如果他们有修复的知识，为什么不呢？我可以看到仍然需要可追溯性的那些地方应该报告错误，并且大概测试人员将首先编写一个失败的测试来演示错误...
#2 楼
作为大型组织中的小型团队的测试人员，我的答案可能会与另一种情况下的测试人员的答案有所偏差。我很适合修复错误的测试人员，但是，我们还需要意识到我们专注于测试，而开发人员专注于编码。我们可以修复它，并且它可以破坏我们不知道的其他东西。最终，在许多组织中，代码归开发人员所有。
实际答案是的，我认为这很好，只要团队对此和代码都满意由与代码有利益关系的开发人员检查和签入。
评论
如果测试人员修复了给定的错误，谁来验证该修复程序？
–乔·斯特拉泽（Joe Strazzere）
2012年11月14日12:09
从理论上讲，这些团队中将有不止一名测试人员。我可能会在今天晚些时候看到有关编辑答案的信息，但是，在这种情况下，确实需要采取某种措施。
– Lyndon Vrooman
2012年11月14日12:33
或者考虑到现在在某些团队中没有如此严格的测试人员/开发人员部门，那么使用测试人员检查修复的开发人员就可以了。 '嘿，我注意到代码完成了<而不是<=“
– Phil Kirkham
2012年11月15日4:20
@JoeStrazzere我猜是开发人员验证了它，然后其他测试工程师重新验证了它，然后如果还有另一个错误（被开发人员验证遗漏了），那么谁先修复了它的测试人员再次对其进行了修复，然后再次开发验证了它，然后循环继续:)
–塔伦
2012年11月15日下午5:40
#3 楼
不，他们不应该。主要原因是Developer的自然作用是支持“程序正在运行”的想法。质量保证的自然作用是直接相反的：证明“程序不起作用”。
如果同一自然人扮演两个相反的角色，则可能导致自身的妥协。
，迟早您会被诱惑：
为了使性能更差，仅满足最低要求，或者进行更差的测试，以避免自己发现错误代码
是的，如果某人有“更换帽子”的经验，则可以将这些角色组合在一起。无论如何，在任何时候，他们都应该清楚地了解自己目前在扮演QA或开发人员的角色。
如果您是QA并愿意进行编码（反之亦然），最好的建议是为不同的项目戴上不同的帽子。这样，您将在Project_1中进行质量检查，而在Project_2中进行开发。
评论
我正在检查房屋并为一块松散的木板提供资金，凸轮我得到了锤子和钉子并进行了修复？
– Phil Kirkham
2012年11月14日13:38
@PhilKirkham不，因为看起来所有木板都是松散的，而且您只发现了一块木板。尝试自行修复它的方法同样是使用胶带将其粘贴，而不是发现所有钉子的长度均为0.75英寸而不是1.25英寸。我看过一些这样的房子。还有一些软件！ :)
–bytebuster
2012年11月14日下午13:53
@PhilKirkham延续住房的隐喻，这是每个人自己的决定，是等待6个月还是在由于相同的指甲问题导致天花板下降时死亡。我喜欢等。 :-)返回SQA，这些规格是最终的判断。如果说“钉子”必须为1.25英寸，但不是，则测试应失败，并向开发人员提出问题，依此类推。但是，质量检查工程师通常会通过接受/粘贴胶带固定确实损坏的东西来妥协自己。我们在这里和那里看到结果。请参阅上方的安德鲁评论。
–bytebuster
2012年11月14日14:44
@bytebuster，根据您的房屋类比，从逻辑上讲，我们不应该依赖单元测试的有效性，因为开发人员编写代码并且他们也编写单元测试。因此，随之而来的是，投资于编写单元测试是浪费的。但是，我们知道这是谬论。另外，您关于测试人员通过“接受/粘贴胶带固定”而折衷的说法是荒谬的。正如您所断言的那样，规格是最终的判断者，而测试人员的作用是证明事情正在正常进行。这些都是过时和过时的偏见。也许这是您的经验，但肯定不是我的。
– Bj Rollison
2012年11月14日16:13
@Phil-如果（作为独立测量师）您正在检查房屋并发现一颗丢失的钉子，不，您无法自己修理。独立测试人员也应如此。
–安德鲁（Andrew）
2012年11月15日20:40
#4 楼
“是的，这很有意义”似乎有很多答案。对“不，你不敢。”我可以看到问题的两面，所以这是中间的一个答案。这要取决于。，这取决于质量保证在特定项目中的作用。
如果QA参与了软件开发生命周期，则QA从项目开始就在定义需求中发挥了作用，并且QA感觉他们在项目的支持下管理部门要发挥积极作用，我会说的很努力。我一直欢迎具有工程学重点的测试人员和质量检查人员花一些时间来理解构成他们所测试系统基础的代码，并且没有比修复项目中的错误更好的学习系统的方法了。
另一方面，如果质量检查不参与整个项目，则在需求阶段和项目实施期间，如果质量检查不在桌上，那么您将要考虑质量检查可能没有足够的信息来修复错误而又不引入更多的复杂性（甚至不了解错误如何影响整个开发工作）。在没有开发人员或项目管理人员参与的情况下进行质量检查修复错误可能会导致一系列问题。也许是由于业务尚未充分说明需求而开发决定推迟功能的实施？也许是因为开发人员正在等待澄清而存在特定错误？
总之，我欢迎在我开发的所有项目中投入更多的质量检查工作，但是只有当我确信他们参与了项目的各个方面时，我才会对质量检查修复代码感到满意。
评论
就像测试中的所有内容一样，它取决于上下文。
– Steve Miskiewicz
2012年12月2日，下午2:09
尽管是IMO，这是一个很好的答案，但在情况2中，我也会非常担心质量检查的有效测试能力。
– testerab
13年3月9日在21:56
#5 楼
是的，如果情况确实如此，他们就可以。如果您遵循敏捷方法论，那么当然，测试人员可以根据需要修复错误。
在敏捷中，边界开发人员和质量工程师的模糊。根据容量和积压，团队成员承担用户故事。并且，如果存在要修复的错误，质量工程师（QE）愿意修复该错误并在以后进行验证-那么他肯定可以。如果需要，他可以介入开发人员的工作（假设他在技术上足够熟练）。
也许，在瀑布式环境中，开发人员和QE角色会重叠的情况下将不存在这种灵活性。 br />
我赞成QE进行并修复错误。更重要的是，在练习白盒测试时，他们非常熟悉代码流。找出代码中的缺失情况，然后修复错误，肯定可以证明QE的技术水平。
评论
这个和其他答案帮助我评估了专业测试人员的意见。谢谢。
– lontivero
13-10-11在4:37
评论
如果有关在线这些家伙的信息？是的，但我不记得在哪里。无论如何，我记得先生在一次会议上。 wittacker（首先来自MS，现在来自Google）谈论测试并将其告知听众。它必须在YouTube中以“测试已死”为名称