在我工作的产品团队中,工程资源如下:


4个开发团队(每个4-5个成员),每个团队都有专门的产品负责人
1质量检查团队(4名成员)

方法1:

当前,单个质量检查团队可以共同工作,以手动测试来自所有4个开发团队的门票。这种方法行之有效,但同时也产生了有关优先级的问题:哪个团队的哪个票证更重要?开发团队如何选择测试人员来分配票证?等方法

方法2:

但是,我们正在考虑的是为每个开发团队分配一名QA工程师。当然,这引起了卡车因素的问题,因为只有一个专门的质量检查工程师与一个开发团队一起工作似乎很冒险,而且效率可能很低。

问题:

根据您的经验,将质量检查团队整合到我们的产品开发中的最佳方法是什么?上述2种方法是否有合理的替代方法?

#1 楼

您的标签中包含Scrum,因此值得注意的第一点是Scrum需要跨职能团队。我认为必须进行质量检查才能将产品交付生产,因此技能需要掌握在团队中。

现在,比率为4:1的情况下,确实存在很大的风险,尤其是在所有的工作都在冲刺的最后一天交给他们。在这方面需要考虑以下几点:

1)没有任何话说来自另一个团队的团队成员在需要时不能提供帮助。这是解决问题的创可贴,但是有时创可贴正是您所需要的。

2)有许多并行运行开发和测试的方法。我强烈建议您查看TDD,BDD和“按示例编写规格”,以获取有关如何不等到sprint结束进行测试的想法。 (我知道这并不涵盖所有类型的测试,但确实有助于将工作分散到整个sprint中)。

3)好的QA工程师的价值不在于运行测试或记录测试。这是在确定要测试的内容–开发人员不会考虑的裂缝和角度。这意味着任何Scrum团队成员都可以承担大量的测试工作。

4)在此模型中,您肯定会失去的一件事就是具有类似技能的人相互帮助。一个简单的“章节”或“实践社区”模型可以使测试人员每周聚会一次,以分享想法和最佳实践,这有助于减轻这种情况。

我在这两个模型中都工作过,开发人员和测试人员。选项2总是给我带来更好的结果。

#2 楼

从质量检查的角度来看:

通常,当一个测试人员被分配到一个团队中时,他/她要经历的测试阶段很少。最重要的是:



哑猴测试:


将系统用作具有'0的全新用户对产品的了解
以不应该使用的方式试用系统。
这可以识别系统的健壮性,安全性问题,处理错误,恢复时间等。



探索性测试:


将系统用作具有“ 0产品知识”的全新用户。
将其用作尝试学习产品的用户。
将其用作尝试理解错误消息,工具提示,按钮设计等的用户,以了解使用产品的正确方法。
这可以识别UX设计中的缺陷,确定可用性,与可访问性相关的问题等。



功能测试:


将系统用作了解领域和产品的领域专家。
以了解业务需求的方式使用系统。
测试高度复杂的业务用例等。



所以提出您的问题:

第一种方法的优点是:

这将使您在“哑猴”测试和探索性测试中获得更多结果。由于测试人员在测试多个产品而不是专注于单个产品的情况下,领域知识和产品知识将受到限制。 (因为我们都是人类,并且在执行多任务时会分心)。

第一种方法的缺点:

测试人员将缺乏领域专业知识和产品专业知识,这可能会导致

第二种方法的优点是:

用户有更多的时间来改善对产品和产品的知识。域。

由于测试人员充分了解产品和领域的复杂用例,因此可以在功能测试中获得更多结果。这样可以确保产品按照预期的方式工作。

第二种方法的缺点:

由于测试人员对产品和领域非常了解,因此有时他们会错过识别可能导致用户无法吸引购买产品的UX缺陷。

因此,探索性测试和猴子测试在这里效率不高(但是熟练的测试人员甚至可以覆盖这部分)

所以我的提示:


对于从头开始构建且不够成熟的产品,第一种方法更好。
第二种方法最适合所有情况,并且可以在早期测试中发现复杂的情况。 (鉴于您不会使测试仪超负荷工作)
如果一个人不能独自处理,则需要更多质量检查。


#3 楼

我的建议是采用另一种方法。

我建议将质量检查分为两个功能:


使用传统方法进行尝试性测试以破坏事物。这将作为一个单独的组保留。
由qe工程师编写的自动测试,他们参与应用程序的开发和针对其的自动测试,并嵌入应用程序团队中。

主要该解决方案的挑战是您需要雇用更多的员工。也许不是两倍。也许2可以做探索性测试。请记住,探索性测试并非详尽无遗,并使用所有数据组合和设备-它更像是一种抽样方法。

正如其他人所指出的,团队中有1个qa / qe ...需要编写UI测试...用于完整的功能...由3个开发人员...在sprint中只剩下很少的时间了...导致此方法不起作用。

评论


为什么不在团队内部同时进行自动测试和探索性测试?我希望在2-3天内拥有DoneDone的新功能,而不需要其他团队。

– Niels van Reijmersdal
20-2-10在10:22

同意,将1个质量检查工作作为小型瀑布是行不通的。学习如何打破小瀑布是。

– Niels van Reijmersdal
20-2-10在10:23

#4 楼

您分享的第二种方法对我来说更有意义。这样,每个质量检查资源将更好地了解单个产品/模块,而不是了解所有四个开发团队的所有知识,因此,更好的结果不会浪费多个域模块上的时间。必要时,质量检查小组通常可以坐在一起讨论整个领域。

#5 楼

方法1只是将工作移交给另一个学科时的瀑布。我不喜欢它,因为它引入了上下文切换,这是在QA和原始DEV团队之间发现乒乓球的缺陷。

对于方法2,请考虑从一个团队开始,如果它可以扩展到其他团队。


仅有一个专门的QA工程师与一个开发团队一起工作
似乎有风险,而且效率可能很低。


它降低风险,因为其他团队成员应该能够承担单点故障的工作。专门的质量保证不是任务负责人,而是帮助和指导其他团队成员提供更高质量的人选。考虑进行成对测试和三阶段会话。

我会考虑为整个团队投资敏捷测试奖学金课程:


三天敏捷团队和测试人员的培训课程。参与者
了解整个软件交付团队可以如何协作计划
并执行将质量纳入其产品的测试活动。


建议的模式:


群聚:单片连续流
三个朋友