测试人员在 Scrum 中的角色是什么？

测试人员在Scrum团队中到底担任什么样的角色？Scrum团队有测试角色吗？测试人员是Scrum团队的正式成员吗？

 

一、《Scrum指南》对测试的看法

很多人认为Scrum团队中的三个角色分别是项目经理、开发人员和测试人员。但其实这三个角色分别是产品负责人、Scrum Master和开发团队。

 

对于程序员、测试人员、数据库工程师、分析人员等角色，Scrum团队不加以区分，他们都是开发团队的成员之一，这更利于培养端到端交付的集体所有权意识。在传统的瀑布式团队下，上级将任务分派给开发人员，开发人员将写好的代码交给测试人员。一个任务接着一个任务传递下去，每个人都会继续处理下一个任务，一切看似都在交接中按部就班地顺利进行。

 

这不可避免地会出现意外，例如出现Bug导致事情没有按预期交付，或者因为某个角色完成速度慢导致工作堆积。而Scrum恰恰可以解决这种排队或交接的问题，让团队共同努力，在每个时间盒冲刺内完成解决方案的一小部分。

 

接下来，我们一起看看如何在Scrum团队中执行测试。

 

二、Scrum团队如何处理测试

首先，最重要的一点：任何头脑正常的人都知道Scrum团队同样需要进行测试，也是有测试人员的，测试是开发的重要组成部分。

 

Scrum团队负责开发产品增量所需的所有工作，包括测试工作。Scrum团队成员可以通过以下多种方法来实现这一目标：

• 团队中的每个人都可以测试自己所编写的代码；
• 团队中的每个人都可以编写自动化测试来测试；
• 在团队中开发人员和测试人员进行配对工作；
• 团队成员可以结对编程，以确保从一开始就是无bug代码；
•  ……

 

这其中也存在团队的开发人员负责测试，典型的测试方法就是双管齐下的：

• 开发人员不仅编写代码，还继续手动或自动化测试；
• 测试人员继续执行手动、自动测试。

 

在理想情况下，验收标准应该在进行任何测试或开发之前确定，预先商定一套具有通用性验收标准有利于首次的正确构建。

 

其实，更好的方法是采用测试优先的方法，将测试置于开发过程的前面。测试驱动开发（TDD）是一种流行的测试方法，开发人员在编码之前先编写一个小型测试以满足测试。除此之外，还有一些测试优先的方法可以将测试思维扩展到整个让团队或团队的利益相关者，如示例需求说明（SBE）、行为驱动开发（BDD）、验收测试驱动开发（ATDD）。

 

根据产品需求，Scrum团队需要进行多个级别的测试，以确保单个功能正确执行，在不会破坏其他任何功能的前提下，正确集成到产品增量中。所有必要的测试都是团队所应该完成的一部分，且需要在同一个冲刺中执行。

 

到目前为止，这听起来非常简单，但落实到实际就会出现各种各样意想不到的问题。我们一起来看看实际中出现的一些出人意料地测试人员的误区。

 

三、关于测试人员的误区

1、最后测试

最后测试是一种常见的误区。开发人员完成代码后根本不进行检查，直接将代码扔给测试人员。一些开发人员通过完成多少行代码编写来衡量工作的进度，然而测试人员通过发现多少bug来衡量进度。在这种情况下，开发人员和测试人员都在忙碌，但实际上他们所做到对整个项目却没有产生任何影响。

 

2、没有商定验收标准

在瀑布式开发的团队中，有时会存在这种情况：测试人员认为自己具有独立性，甚至认为自己比程序员更了解系统。这可能会导致测试人员没有与团队同步正在使用的验收标准，那出现代码无法通过测试的情况也不足为奇。这就需要测试人员和开发人员对验收标准达成一致，以确保每个人都有相同的目标。

 

3、 “我的工作是破解你的代码” 

一些测试人员将破解代码视为自己的主要工作。Scrum团队成员的目标应该具有一致性，是为了提供有价值的解决方案。测试人员进行测试并不是为了破解代码，而是为了确保软件能够按照预期上线。在这种情况下，测试人员应与开发人员密切合作，以有效地构建高质量的解决方案，并避免出现解决不必要的bug而浪费时间的情况。

 

4、 “我是唯一可以进行测试的人” 

⌈只有一个人有测试权限⌋，这恰恰是许多企业或组织对测试的常见误区。如果只有一个人有测试权限，那么当他不在场时是否要停止工作？显然不能，因为这会造成项目的积压，因此团队必须共同参与测试工作。

 

5、“如果没有他们，我们本来可以完成”

团队中的开发人员和测试人员之间会出现明显的分工和隔离，表现的完全像是两个不同的团队。发生这种情况主要是因为团队成员倾向于依赖熟悉的工作方式，他们只专注于完成自己的任务，而忽略了提供客户价值的更大目标。相比于此，一些企业为开发团队和测试团队保留了独立的组织结构，建立厚重的部门墙，这阻碍了两个部门之间的沟通与交流。

6、支持多个 Scrum 团队的测试人员池

测试人员会根据团队需求提供测试支持，但每个团队都会堆积未经测试的代码，这使得测试人员将其视为待处理的任务堆积。在这种情况下，测试人员往往不是团队的一部分，他们可能没有权力参与交付过程，甚至可能错过待办事项细化会议，不了解他们正在测试的项目或客户的需求。

结果是相当可预测的：测试人员有大量甚至重复性的测试工作，但对客户交付方面没有价值意义。这通常不是为了巩固专业知识，而是为了保护某些测试经理的位置。

 

7、设立卓越测试保证中心

一些企业在建立卓越测试中心方面可能会走向错误的方向。当代码存在问题时，企业可能会设立一个特定部门负责质量，以解决这个问题。然而，问题在于卓越测试中心无法直接改变代码质量，其职责只是揭示其他人需要解决质量问题了。

 

举个例子：

所有测试和质量保证人员都是卓越测试保证中心的成员，他们向CoE经理汇报。该经理要求每个测试人员每周提交一份关于他们发现的Bug数量的报告。测试人员1发现了20个bug，测试人员2发现了40个bug，他们谁做得更好？如果测试人员没有找到20个bug，还需要更加努力吗？要不要修改bug数量报告以获得更多bug或更少bug？

 

这一系列疑问表达了一个常见的问题：将测试的效果仅仅归结为缺陷数量的报告。这种方法可能会导致测试人员为了追求数量而牺牲质量，或者感到受到惩罚或奖励的压力。这并不能真正改善产品的质量，而只是创造了一个表面上的指标。

 

8、“当你开发时我们的测试人员正在睡觉”

一个有趣的想法是在开发人员睡觉时让一组离岸测试人员进行过夜测试。乍一看，这个想法具有可操作性，特别是试图降低测试人员的每小时成本。

 

然而，将测试外包给离岸测试团队是毫无意义。首先，测试人员无法及时与开发人员沟通和解决问题，这实际上增加了更多的沟通成本，这会对质量和交付产生不同程度的影响。团队想要提高效率，就需要整个团队成员（包括测试人员）都要对工作内容有共同的理解。

 

9、所有测试用例和结果都需要写在我们的标准工具中

使用适当的测试工具可以提高测试效率和质量，但要意识到工具只是辅助手段，而不是唯一的衡量价值的标准。

 

不少企业强制使用标准测试工具是为了通过工具生成的报告来展示测试团队为流程增加的价值。强制使用工具只是管理者通过报告活动来展示价值的一种方式。然而，这种方法忽略了一个重要的事实：价值不在于活动本身，而在于向客户交付的解决方案。

 

测试团队的真正价值在于他们能够发现问题、提供质量保证和改进产品的质量。而这些价值往往无法完全通过报告来展示。因此，重要的是要将关注点放在为客户提供高质量的解决方案上，而不仅仅是工具和报告。

 

10、我们只是修复关键bug

“所有软件都有Bug，在sprint结束时不可能做到完全没有bug。”如果团队抱有这种想法，那么他们就无法准确地执行计划，因为每个sprint都可能会出现一个重大的生产问题。

​

11、故障单羽毛球

在软件开发过程中，使用bug跟踪工具作为开发人员和测试人员之间的沟通方式是很常见的。团队通常会将Bug报告通过bug跟踪工具分配给开发人员，开发人员收到通知后进行查看。

 

然而，如果团队成员过于关注关闭时间的指标，可能会导致一些问题。例如，如果存在积压的项目和缺乏明确的验收标准，那么测试人员会面临大量的任务。每个成员都知道时间正在流逝，因此他们会尽快关闭或重新分配工单。

 

在这种情况下，团队成员不是进行真正的对话，而是利用该工具的“力量”来回移动任务以进行交流，这会导致沟通不畅或责任转嫁等问题。

​

12、生产中的测试

开发人员不测试代码，团队就连测试人员也没有。试想一下，代码未经任何测试就投入生产会产生什么样的后果可想而知。

 

​

四、写在最后

对于技术团队来说，测试是一项至关重要的活动。专门从事测试的人最好退一步思考如何创造客户价值、测试的目的以及引入缺陷所造成的浪费。

• 产品待办事项列表 引入冲刺的项目应该在冲刺中一直完成。
• 那些被视为完成的项目应该完全是零缺陷。
• 测试的良好实践包括测试优先的方法。
• 测试和质量是整个团队的责任，而不仅仅是一个接受过培训且头衔恰好是测试员的人的责任。

最后，我们要明确一点，Scrum团队不对具体开发团队的成员职责加以区分，他们都是开发团队的成员之一。测试人员与其他团队成员共有同一个职责：在冲刺结束时开发一个潜在可发布产品增量，以实现冲刺目标。