质量保证人员应该编写一些生产代码吗？开发人员应该做一些质量保证吗？

Question

在足够小的组织中,是否应该有完全独立的QA和Dev角色,或者每个角色是否需要一些时间(例如,每周1天)扮演另一方的角色？

我不是在谈论单元测试.我在谈论一个关注系统的QA,它也会贡献一些生产代码,而开发人员花费一些时间来分析和测试系统的一个独立部分.

在我看来,这种杂耍可能是有意义的,因为质量保证在系统中获得了更好的理解和个人利益,而开发人员在单元测试之外更好地理解质量和测试问题.但我相信也有理由反对它......

Answer 1

有些要考虑的要点:

• 据推测,你雇佣了你的开发人员,因为他们擅长编写代码,而你的测试人员因为他们擅长QA而受雇.从商业角度来看,支付他们做彼此的工作是否有意义？
• 如果您的测试人员对代码的理解程度太高,他们会发现盲点吗？
• 同样,您的开发人员是否真的能够成为有效的测试人员,他们对应用程序有着深入的了解？

Answer 2

作为一名QA人,我发现这个想法很有趣.有机会开发专业代码听起来像个好主意; 我也喜欢将开发人员暴露给QA世界的想法,因此他们知道如何提倡缺陷修复.

以下是关于这种方法的优缺点的一些想法.

优点:

1. 质量保证会在真正的开发环境中获得更好的感觉.很多时候,QA被降级为临时脚本创建,其中自动化测试以稍微匆忙和滑稽的方式编写.这可能使他们有机会将他们的视野扩展到更有条理的开发周期.这也可以为他们如何编写脚本提供一些见解,并可能为更好的测试开发提供一些想法.
2. QA可能在发布周期中有更多的利益.虽然从个人的角度来看,我会说我将自己的骄傲与我们的发布和质量联系在一起,但有时真的看起来QA对整个产品的投入不大.我们经常被视为"错误发现者",而不是工程师,我想知道这种方法是否会给QA团队带来更大的专业性(缺乏更好的词汇).
3. 开发人员可能会更好地感受质量保证作为一种做法.我经常让开发人员告诉我他们不知道我以什么为生.让开发人员测试代码可以让他们略微尝试"吃自己的狗粮",可以这么说.
4. 这将使QA有机会扩展他们的简历.我认识的许多质量保证人员都关注他们的适销性.优秀的开发人员通常能够相对快速地获得工作; 测试位置似乎更难找到.任何有助于员工扩大他们在该领域的经验的东西都是一个有吸引力的建议.

缺点:

1. 不应依赖开发人员来测试他们自己的代码.同样,不应依赖QA来测试自己的代码."交叉授粉"(窃取兰斯的优秀短语)是危险的,因为它可能导致人们验证自己的工作.一般来说,这不是一个好主意.人们常常对自己的缺点或错误视而不见,并且在第三方测试时,开发的代码最好经过验证.当然,适当监控和管理这个过程可以减轻这个过程......但这是一个问题.
2. QA不是专业开发人员,开发人员也不是专业QA.每当开发人员给我代码他/她已经"测试"时,我就会畏缩.并不是我瞧不起他们的技能组合:相反,我无法编写他们拥有的代码.但我也认识到我们对"测试代码"的定义之间存在差异.同样地,作为一名质量保证人员,我不希望我的代码能够为客户提供高可见性,这可能会损害或阻碍客户的关系.注意:我并不一定意味着关键任务:有时候客户关系会受到简单的可用性缺陷的影响 - 这对于不成熟的开发人员来说是一个常见的错误.我担心的是高可见度(我认为这包括关键任务); 我知道我不是一个专业的开发人员,我不想保持同样的标准.
3. 这增加了返工的机会.我不一定信任开发人员充分测试代码,他们不应该测试我充分开发解决方案.在这两种情况下,某人需要重新回到以前的工作中去做"正确"的可能性将是一个问题.

总的来说,我认为这个想法非常有趣,听到有关这个故事的故事会很棒.

我参与的一个类似方法是"bug days".在这些日子里,开发人员坐在QA旁边,他们合作找到尽可能多的缺陷.像这样的日子非常出色:QA和开发团队之间的专业关系得到加强,对彼此技能的尊重通常会增加:开发人员可以更好地了解QA如何发现错误,QA可以更好地了解开发人员在他们发出嘎嘎声时知道多少解决你发现的bug.这不是解决问题的完美方式:QA仍然没有做太多的生产级代码.但它确实有助于促进各职位之间更好的理解.