首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >如何将4名QA工程师集成到4 dev (Scrum)团队中?

如何将4名QA工程师集成到4 dev (Scrum)团队中?
EN

Stack Exchange QA用户
提问于 2020-02-07 20:37:37
回答 5查看 222关注 0票数 8

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

  • 4个开发团队(每个团队有4-5名成员),每个团队都有一个专门的产品负责人
  • 1个质量保证小组(4名成员)

方法1:

目前,单个QA团队一起工作,以便手动测试来自所有4开发团队的票。这种方法是可行的,但它也会产生关于优先级的问题:哪个团队的票证更需要测试?开发团队如何选择测试人员将票分配给?等。

方法2:

不过,我们正在考虑的是,为每个开发团队指派1名QA工程师。当然,这引起了卡车因素的问题,因为只有一个专用的QA工程师可以与单个开发团队一起工作,这看起来很危险,而且可能效率低下。

问题:

根据您的经验,将QA团队集成到我们的产品开发中的最佳方法是什么?上述两种方法是否有任何合理的替代办法?

EN

回答 5

Stack Exchange QA用户

发布于 2020-02-07 21:15:47

您的标签中有Scrum,因此值得注意的第一点是Scrum需要跨功能的团队。我假设QA需要将产品交付到生产部门,所以这种技能需要在团队中进行。

现在,有了4:1的比例,他们就有被压垮的危险,特别是如果所有的工作都在冲刺的最后一天交给他们的话。以下是在这方面需要考虑的几点:

1)如果需要的话,来自另一个团队的团队成员什么都不会说是帮不上忙。这是一个解决问题的绷带,但有时一个绷带正是你所需要的。

2)并行运行开发和测试的方法有很多。我强烈建议查看TDD、BDD和Spec逐例,以了解如何不要等到sprint结束后再进行测试。(我知道这并不包括所有类型的测试,但它确实有助于将工作扩展到整个sprint)。

3)一个优秀的QA工程师的价值不在于运行测试或记录测试。它是在确定什么是测试-裂缝和角度,开发人员没有考虑。这意味着任何scrum团队成员都可以承担大量的测试工作。

4)在这一模式中,你肯定会失去一件事,那就是拥有相似技能的人互相帮助成长。一个简单的“章节”或“实践社区”模型,让测试人员每周聚会一次,分享想法和最佳实践,有助于缓解这一问题。

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

票数 4
EN

Stack Exchange QA用户

发布于 2020-02-08 10:30:12

从QA的角度看

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

  1. 哑猴测试
    • 使用系统作为一个全新的用户谁有'0的产品知识‘
    • 以一种不被使用的方式尝试这个系统。
    • 这允许识别系统的健壮性、安全性问题、处理错误、恢复时间等。

  2. 探索性测试
    • 使用系统作为一个全新的用户谁有'0的产品知识‘
    • 将其用作试图学习该产品的用户。
    • 将其用作试图理解错误信息、工具提示、按钮设计等的用户,以理解使用产品的正确方式。
    • 这允许识别UX设计中的缺陷,识别可用性,与可访问性相关的问题等。

  3. 功能测试
    • 使用系统作为领域专家,谁知道领域和产品。
    • 以一种了解业务需求的方式使用系统。
    • 测试高度复杂的业务用例等。

来问你的问题:

第一种方法的优点是:

这将给你更多的结果,在麻木猴子测试和探索性测试。作为测试人员,领域知识和产品知识在测试多个产品的场景中将受到限制,而不是集中在单个产品上。(因为我们都是人类,当多重任务时会分心)。

第一种方法的

缺点:

测试人员将缺乏领域专家和产品专业知识,这可能会导致错过测试复杂的业务场景和错误被推向生产。

第二种方法的优点是:

用户在改进产品和领域知识方面有更多的时间。

这将在功能测试中提供更多的结果,因为测试人员非常清楚产品和领域的复杂用例。这样可以确保产品按其预期的方式工作。

第二种方法的

缺点:

由于测试人员非常清楚产品和领域,有时他们在识别可能会阻止用户购买产品的UX缺陷方面漏掉了。

因此,探索性测试和猴子测试在这里效率较低(但熟练的测试人员甚至可能涵盖这一部分)。

所以我的小贴士:

  1. 第一种方法更适合于那些从零开始构建且还不够成熟的产品。
  2. 第二种方法对所有场景都是最好的,可以在早期测试中找到复杂的场景。(假设您没有使测试人员过载)
  3. 如果一个人无法独自处理,请雇佣更多的QA。
票数 2
EN

Stack Exchange QA用户

发布于 2020-02-08 10:46:56

我的建议是采取不同的方法。

我建议将QA分为两种功能:

  1. 使用传统方法的探索性测试来尝试和破坏一些东西。这将保持为一个单独的小组。
  2. 由qe工程师编写的自动化测试,他们参与了应用程序和自动化测试的开发,并嵌入到应用程序团队中。

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

正如其他人所指出的,在一个团队中有一个qa/qe .需要写UI测试..。这是为了完成功能..。由三个开发商..。在短跑中只剩下很少的时间了..。导致这一切只是行不通。

票数 1
EN
页面原文内容由Stack Exchange QA提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://sqa.stackexchange.com/questions/42468

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档