测试工程师在敏捷项目中扮演什么角色？

敏捷团队中的测试人员主要负责执行各种测试，以满足“已完成”的定义，从而为团队在重复迭代中努力交付的持续价值创造做出贡献。对于测试人员来说，拥有敏捷的心态是至关重要的，如果没有敏捷的思维方式，他们可能就不能果断地计划、划分优先级并执行他们的任务，因此会无意中影响团队满足迭代目标的能力。敏捷的思维方式是测试人员展示正确行为的先决条件，这些行为能够加速整个团队的性能。

为了在敏捷项目中取得成功，测试人员应该关注以下实践：

1.态度胜过一切

团队中的测试人员可能不具备敏捷背景、自动化技能或丰富的测试经验——只要他们具备成为敏捷团队一员的正确态度，这仍然是可以的。正确的态度会反映在以下行为中，比如：相信敏捷宣言和实践，信任教练并全力以赴地遵循它，对新的学习和变化持开放态度，清晰表达和透明，致力于对团队重要的活动，在这段时间内主动改进和变得更好等等。

敏捷、自动化、测试或其他培训，对于拥有正确态度的人来说，是可以齐头并进的。

根据既往经验，在工作中使用僵化思维的测试人员减慢了迭代的进度。有些行为是——仅在ALM工具中更新状态时才测试缺陷；在测试环境关闭时，闲置而不在本地主机上执行健全性测试；考虑在会议期间单独测试活动；在部署时坚持团队成员的正式沟通，阻止决议和暗示等。

相反，以开放的心态来的测试人员转变了自己，为团队服务，并以各种可能的方式做出贡献，例如，他们中的一些人在空闲时间编写Junit案例来帮助开发人员，学会编写服务来模拟测试环境，在高度动态的环境中灵活调整计划和测试方法。

2.将迭代目标优先于外部分配

在矩阵式组织结构中，测试人员在敏捷团队中与Scrum Master一起工作，但他们向测试实践部门的直线经理或同一项目中的测试经理报告。这些在敏捷团队中驱动整体测试的测试经理，可能会给测试人员分配许多与团队迭代计划不一致的特别任务。

在与测试人员的多次接触中，我发现他们很难在两方面之间取得平衡——兼顾绩效评估和致力于工作。他们中的大多数人都试图在没有通知敏捷团队的情况下承担外部任务，因为他们不想让直属领导不高兴。一些人知道它会影响正在进行的迭代活动，于是通过延长工作时间即加班来完成这些任务，但也有很多人牺牲了迭代活动。由于这种妥协，他们无法交付迭代目标，这导致了用户故事的常规溢出，也影响了团队的信任和内聚水平。

在这种情况下，测试人员应该怎么做？答案是——迭代活动应该总是优先于任何其他活动。但是，如果他们能够在不影响迭代目标的情况下完成外部任务，那么他们就可以继续！但是，如果外部任务有可能影响迭代目标，那么他们应该咨询团队以获得集体同意或意见分歧，并将决策告知直属经理。

3.跨职能团队中的关系平等

“我不能测试这个用户故事，因为开发人员没有部署它”，一个测试人员在每日站会中说，开发人员回答说：“抱歉，我忘了它，但你也应该联系其他开发人员来完成。”。这个场景突出了团队缺乏协作和所有权。推动一个用户故事的完成并消除间歇的阻碍因素并不是个人的责任，而是团队的努力，作为团队一部分的测试人员也不例外。

测试人员的某些行为有助于加快交付速度——无论是否与测试相关，都需要关注到阻碍因素；经常与开发人员同步，而不是通过电子邮件沟通；积极参加scrum会议以提高团队的决策能力，与团队的计划保持一致，从而使他们的活动保持一致等等。

一些与其他团队过度交往的测试人员更喜欢挑选低优先级的任务。因为他们需要花费数小时来解决其他团队的问题，却以牺牲自己的工作为代价——这种行为超出了在跨职能团队中作为平等伙伴的边缘。团队成员应该优先解决他们的问题，如果需要的话，为其他团队提供帮助应该是次要的目标。

4.假设并不是一种选择

有时，利益相关者的评审意见显示，团队在验收标准方面存在一些不必要的假设。假设不是特定的对测试人员的选择，因为测试是工作流中的最后一个活动，因此也是团队中任何人验证需求的最后机会。此外，测试人员的专长在于发现有问题的可交付成果。

我了解一些让测试人员陷入不合理假设的根本原因。这些原因是：害怕被人评判他们提出正确问题的能力，对他们以前的问题没有得到适当的答复，沟通能力差，使他们无法抓住任何机会，缺乏一个安全的环境来公开挑战接受标准，或者在积压工作改进会议期间无知，不提出问题需要澄清的问题。

在敏捷项目中，假设的成本太高了，因为产品增量很快就会推出给最终客户——交付的任何缺陷都会影响投资回报（ROI），并需要返工，消耗的预算超过了功能的价值。

迭代经理、Scrum Master或教练使用诸如5个为什么之类的技术对这些根本原因进行彻底的分析，对于设计有效的指导计划和在随后的迭代中控制这些行为非常有益。