对于初涉敏捷的测试工程师来说，如果定位自己的角色和职责、如何从传统开发模式成功迁移到敏捷模式、如何跟上短迭代的节奏等等问题都迫切地想要找到答案。 资深敏捷实践者Lisa Crispin和Janet Gregory在《敏捷软件测试：测试人员与敏捷团队的实践指南》一书中，列举了敏捷测试工程师的十条法则，对读者或许有借鉴意义。

　　提供持续反馈（Provide Continuous Feedback）

　　既然是测试驱动敏捷项目，那么很显然反馈在敏捷团队中占据重要的地位。测试人员的传统角色就是“信息提供者”，这使得她天生就对敏捷团队很有价值。敏捷测试人员的最大贡献之一是帮助产品负责人或者客户采用实例和测试的形式描述清楚每一个用户故事的需求。然后，测试人员与团队同事将这些需求转化为可执行的测试。测试人员、开发人员和其他团队成员尽快运行这些测试，并不断接收有意义的反馈。

　　为用户创造价值（Deliver Value to the Customer）

　　敏捷开发就是在较小的版本发布中提供客户目前最迫切需要的功能。这通常意味着限定范围。我们经常在客户团队中遇到较酷功能的需求。任何人都可以质疑这些内容，但是测试人员会判断其对故事的影响，因为他们需要考虑测试后果。

　　敏捷测试人员需要总览全局。我们可以在当前迭代中发布最重要的功能，稍后再完善。如果让新功能偷偷混进来，就面临一无所获的风险。如果过于关注边边角角，而忽略了核心功能，就无法提供业务所需的价值。

　　促进面对面的沟通（Enable Face-to-Face Communication）

　　敏捷测试人员从客户的角度思考每一个故事，但是也理解实现功能相关的技术和局限性。他们可以帮助客户和开发人员达成共识。业务人员和软件人员经常使用不同的语言。他们不得不找到一些共同点来协作。测试人员可以帮助他们达成一种共通语言。

　　面对面的沟通是不可替代的。敏捷开发依赖于持续的合作。就像其他敏捷团队成员一样，从事测试工作的人会不断寻找客户和技术团队成员来讨论和合作。当敏捷测试人员对某个隐藏的假设或者误解的需求产生怀疑时，她会与客户和开发人员讨论。如果处于不同地点的人需要交谈，他们会试图寻找创造性的方式替代面对面、实时的交流。

　　勇气（Have Courage）

　　当最初加入敏捷团队或者当前的团队开始过渡到敏捷开发模式时，通常会产生恐惧感，并且存在大量的问题需要答案。我们到底如何才能在如此短的时间内完成每一个用户故事的测试任务？测试如何跟上开发的节奏？如何确定多少测试就够了？又或者你是功能测试经理或者质量过程经理，不清楚在敏捷团队中如何定位自己的角色，没人知道答案。敏捷测试人员需要勇气找到这些问题的答案，但是除此之外还有其他原因。我们需要勇气允许自己失败，至少我们会短暂失败，并从中学习教训。在由于构建版本不稳定导致一次迭代失败之后，我们开始寻找方法以确保这种事情不再发生。

　　简单化（Keep It Simple）

　　简单并不意味着容易。对于测试人员来说，这意味着采用能够找到的最轻量级的工具和技术恰到好处地测试。工具可以简单到只是一张电子表格或者清单。需要自动化回归测试，但是应该把它们分解到最底层以获取快速反馈。甚至简单的冒烟测试也可能满足面向业务的测试自动化。