为什么Scrum指南不说测试员？

14

我一直在阅读scrum.org上的《 Scrum指南》，它说：

开发团队不包含专门用于特定领域（例如测试或业务分析）的子团队。

在其直译中，这意味着没有令人困惑的测试人员。他们如何建议呢？

scrum

— 皮特2k
source

4

从字面上看，这意味着也没有程序员。没有业务分析师。一个恰当的比喻是，每个人都是幸存者，其工作是做（并学会做）帮助每个人生存所需的一切。

— rwong

3

不，那根本不是直译。它说没有专门的子团队，仅此而已。您可以将您的团队划分为多个子团队来解决问题，但是这些团队应该能够混搭在一起。它没有没有测试人员就没有什么可说的。

— zzzzBov 2012年

25

这意味着：

测试人员已集成到开发团队中-构建工具以帮助开发人员进行测试以及测试。

要么：
团队练习“测试驱动开发”-即，他们编写用于测试系统的自动化测试。

这些都意味着不需要单独的测试团队。

— ChrisF
source

对于创业团队来说，TDD将是更好的方法。我坚信，当测试人员和开发人员在新手团队中一起工作时，测试就成为一个问题。你说什么？

— Maxood 2012年

4

@Maxood：我想说的是，TDD绝对不会使手动测试变得多余。如果有问题，您可以解决；您不会开始回避它。

— Michael Borgwardt

@MichaelBorgwardt非常正确！但是，如果您发现测试人员忙于单元测试，而这主要是开发人员的工作，该怎么办？我觉得只有在代码优化和应用程序可伸缩性等方面才可以使用前一个选项。您怎么说？

— Maxood 2012年

7

@Maxood：我认为测试人员不应接触单元测试。他们应该与开发人员合作进行验收测试，并负责手动/ GUI测试。单元测试的水平只有开发人员才感兴趣。测试金字塔（blogs.agilefaqs.com/2011/02/01/inverting-the-testing-pyramid）也具有响应能力，单元测试=开发人员，验收测试=共享，GUI测试=测试人员。

— martiert

12

在其直译中，这意味着没有使人感到困惑的测试人员……他们如何建议呢？

对，这就是正是他们的建议。换句话说-开发人员是测试人员，而测试人员是开发人员。

这个想法是为了提高代码的所有权和质量。

这并不意味着未对代码进行测试，而是意味着编写代码的人员就是测试代码的人员-没有职责分离。

这种方法试图解决的问题是开发人员和测试人员之间过于常见的分离，即开发人员将编写代码并将其“扔到墙上”给另一个团队，然后它来回往复，从而延迟了项目并生产了不合标准的软件。

— 奥德
source

2

我强烈建议A人测试B人的成长。为了避免“自己的代码盲目性”的陷阱，scrum提出了什么建议（如果您既是功能X的开发人员又是测试人员，则您不会在所有方面都行使代码，因为您知道代码的编码方式并假设必须这样做）工作，还是下意识地避免了弱点）？

— Marjan Venema

1

@MarjanVenema-A人写的内容可以由B人测试，或者在编写任何代码之前先编写自动测试。

— Oded 2012年

5

所有开发人员的质量保证盲目性永远不会消失。行业中发生的事情是，人们对“质量保证与开发”的评价过高，创建了“掷墙”系统，然后出现了反弹。开发人员和质量检查人员是一个团队的成败，但是质量检查人员的角色和技能与编码不同。编码人员需要进行开发测试，而单元测试是QA的一部分，但不是全部QA功能。同样，质量保证角色通常涉及在尚未变得“敏捷”到不再停止编写技术文档的地方创建文档。

— 沃伦·P

6

以我的经验，正是角色的分离使测试人员可以从最终用户的角度查看软件，并发现比开发人员更多的错误。最终产品绝对不是“不合格”产品。

— Giorgio

2

质量检查和发展是具有两种不同技能（和薪级表）的两个不同角色。出色的质量检查需要一定程度的专注和专业，如果有人同时承担开发人员和质量检查的双重职责，就不会发生这种情况。

— 13年

2

对此的基本部分是，编码人员的责任是创建可以工作并满足要求的代码。这需要一种特殊的心态-“我正在编写的代码完成了应做的事情。”

混合编码人员的职责意味着现在需要编码人员为其他活动输入其他思维方式，但是，作为编码人员，很难将自己与该思维方式完全离婚。

测试人员的责任是查找错误和功能从所需功能转移到的地方。这需要“代码已损坏，我将找出方法”的思路。

同样，业务分析师正在尝试确定客户实际要求的要求。这需要另一种心态：“应用程序无法以这种方式工作，但是应该可以。”

为了使编码人员能够以任何其他身份工作，编码人员很有可能会出现思维冲突，并且编码人员将执行低于标准的要求：

编码器/质量检查人员-“代码可以完美运行，而且我已经进行了编码，可以处理我认为可能会破坏它的所有可能方式。”
编码器/ BA-“代码应该按照我想要的方式工作，而这是客户没有想到的要添加的整洁的东西。

这并不是说每个编码器都容易遇到这些问题（我遇到了一些非常有天赋的编码器/ QA类型……尽管不是针对他们编写的代码）。

这也扩展到了开发团队。将开发人员的职责和这些职责的相关心态混合在一起会损害最终产品（代码）。

— 地理编码
source

1

它说没有专门负责测试的小组。这并不意味着没有任何测试。这仅意味着团队成员将进行自己的测试，并经常测试其他人的代码/功能。我对Scrum方法并不熟悉，但我会弯腰说客户也可能参与测试。

— 马可菲塞特
source

“客户也可能参与测试”-是的，完全正确，否则，您有一个瀑布式项目，其中完成的定义是“我们已经到达项目的结尾”。那不是敏捷。

— 罗宾·格林

1

我认为，这部分意味着您应该为自己的代码编写测试，以便知道它是否有效（如果没有，您尚未真正完成它），部分意味着，您有时可能希望成为其他人的代码的测试者。

与其允许人们将软件质量工作转移给其他人并忽略它，不如说这迫使每个人始终从质量角度考虑他们正在编写的代码，因此这是一个好主意。

— 马特·吉布森
source

1

该声明基本上是在试图避免孤立的工作。解决方案的一部分包括一些实践，例如-测试驱动开发-结对编程-拉取请求-测试自动化等，这些都使测试成为开发过程的固有部分，而不是孤立地在侧面或侧面完成。 '后'。

此外，《 Scrum指南》中关于角色的讨论非常有限。实际上，他们谈论的是开发团队。他们的意思是您想要一个强大的跨职能团队。这意味着，取决于项目的需要，您需要一系列技能，例如UX，BA，QA / Tester，Ops，Coder等，但是这是否是涉及这些的一个或多个人并不重要。

与我们一起工作的团队和我们的DevOps员工一样，肯定会担任质量检查的角色。但是他们都是开发人员，只是在这些领域具有专长。真正的诀窍是不要陷入孤岛，孤立地工作。

— 用户名
source

1

这不一定意味着没有测试人员。Scrum团队可能有专门的测试人员，也可能没有。

对我而言，有关Scrum的声明意味着您应该将整个交付流程视为一个团队来考虑。成为同一个团队的一员有以下几点建议：

对故事/错误/任务只有一个估计。没有开发估算和测试估算。
在测试人员不在场的情况下，团队不会估算故事并致力于该故事。
如果出了问题，那不仅仅是测试人员的错，而不仅仅是开发人员的错。 这是团队的错。
团队永远不需要借用，请求或要求测试人员。
测试是完成定义的一部分。未经测试的工作是不完整的工作。
开发人员在设计代码时应考虑可测试性。

如果他们在一个团队中一起工作，那么团队会一起成功而失败。我一直在一个非常成功的Scrum团队中，该团队有数名测试人员。在所有站立，梳理会议，计划等过程中，测试人员都在场。如果不清楚如何测试故事，团队将不会致力于。估算时，我们总是与测试人员交谈。

即使您认为自己确实这样做，也可能没有真正将测试人员视为交付团队的一部分的潜在迹象：

测试人员有一个“ QA标准”（是的，我已经看过）。
测试人员具有单独的管理结构。
您有质量检查线索。
您严重依赖端到端测试。
测试被写成以下冲刺。
大多数测试发生在冲刺的最后一天。

这些是主观的，不一定是错误的。我认为它们是危险信号。

综上所述，在没有指定测试人员角色的情况下，有可能建立一个Scrum团队。那也可以很好地工作。特别是如果您使测试自动化。TDD也有帮助。

— 布兰登
source