敏捷测试人员的十条法则

　　敏捷团队里的每一个人都是一名测试人员，任何人都可能承担测试任务。如果这种说法是正确的话，那么对于一名敏捷测试人员来说有什么特别之处吗？如果我把自己看做是敏捷团队的测试人员，这到底意味着什么？敏捷测试人员相比传统团队里的测试人员需要不同的技能吗？有什么日常工作指南吗？

　　本章将讨论敏捷测试思维，看一看敏捷价值和准则如何指导测试，对测试人员如何为敏捷团队创造价值做一个概述。

　　1、敏捷测试人员的定义

　　我们这样定义敏捷测试人员：专业的测试人员，适应变化，与技术人员和业务人员展开良好协作，并理解利用测试记录需求和驱动开发的思想。敏捷测试人员往往具有的技术能力，知道如何与他人合作以实现自动化测试，同时也擅长探索性测试。他们希望了解客户在做什么，以此更好地理解客户的软件需求。

　　谁是敏捷测试人员？她是驱动敏捷测试的团队成员。我们知道许多敏捷测试人员刚开始的时候在从事其他工作。开发人员可能会爱上测试而超越单元测试的范畴。习惯以敏捷方式工作的探索型测试人员也会被敏捷团队吸引。其他角色的专业人士，比如业务或者功能分析师，也可能具有同样的特质并做同样的工作。

　　技能很重要，但态度更值得关注。Janet总是说：“如果态度不好，那么技能则一无是处”。既然我们要为敏捷团队招募大量的测试人员，那么必须慎重考虑这一点，并与敏捷社区的其他朋友进行相关讨论。测试人员往往可以总览全局。他们更多时候是以客户的角度看待应用程序，这意味着他们一般以客户为中心。

　　2、敏捷测试思想

　　如何使一个团队变得“敏捷”？对我们而言，敏捷团队持续关注如何出色地工作并发布的产品。根据我们的经验，这需要大量的训练、学习、时间、实验和协同工作。这并不适合所有人，但是对那些希望自己团队充满活力并关注持续改进的人来说非常适合。

　　成功的项目总是因为的人才完成了出色的工作。在敏捷团队中做一名成功的测试人员所需要的特质可能与在任何团队做一名高水平的测试人员所需要的相同。

　　敏捷测试人员不会把自己看作是质量管理办公室的主管以保护客户避免受到缺陷代码的伤害。她会乐于收集和分享信息，与客户或者产品负责人协作以帮助他们充分展示自己的需求，从而得到他们需要的功能，同时向所有人提供项目进展的反馈。

　　敏捷测试人员，可能包括其他拥有正确技能和思想的测试人员，都在不断想办法使团队能够更好地开发高质量的软件。对个人来说，这可能意味着需要出席本地用户组会议或者圆桌会议看看其他团队在做什么，同时寻找新的工具以帮助团队通过测试描述、执行和自动化用户需求。

　　基本要求是敏捷测试人员和其他敏捷团队成员一样，乐于学习新技能和面对新挑战，不会仅仅局限于测试问题。这不只是测试人员的特征，所有敏捷团队人员都应具有。敏捷测试人员帮助开发人员和客户团队解决可能出现的任何问题。测试人员提供信息以帮助团队回顾和了解哪些方案有效、哪些无效。

　　创造力、接受新思想、乐于承担任何任务或角色、重视客户和持续关注全局只是敏捷测试思想的组成部分。的测试人员都有一种直觉和理解力：软件可能在何处失败？因为什么失败？

　　测试人员可能在测试领域拥有特殊的技能和经验，但是一名的测试人员并不惧怕参与一场设计讨论，提供有助于测试性或者构建更良好方案的建议。敏捷测试思想是面向结果的、技术性的、协作的、乐于学习的、勇于不断生产业务价值的。

$news-page$

　　3、应用敏捷法则和价值

　　个人能够对项目的成功产生巨大的影响。我们当然认为拥有丰富经验、优良技能的成员的团队会强于人员素质较差的团队。但是，一个团队不仅仅是个人成员的集合。敏捷价值和准则强调的是对参与项目人员的关注和他们如何交互和沟通。应用敏捷法则和价值的团队比拥有众多人才的运作较差的团队具有更高的团队意识和效率。

　　我们在本章开始展示了敏捷宣言中的4条价值声明，阐述了其偏爱的思想，但这不是终判决，并没有说明应该怎么做，不应该怎么做。敏捷宣言还包括了一系列进行软件开发的法则。我们的敏捷“测试”法则部分继承于它们。因为我们都是来源于极限编程文化，所以已经采用了很多其中的价值和基础法则。我们也会结合自身团队总结的规则和指南。当选择了工作的方式并做出决定之后，团队的价值观和法则将会指引具体工作。

　　我们认为以下法则对敏捷测试人员非常重要：

　　● 提供持续反馈

　　● 为客户创造价值

　　● 进行面对面的沟通

　　● 勇气

　　● 简单化

　　● 持续改进

　　● 响应变化

　　● 自我组织

　　● 关注人

　　● 享受乐趣

　　（1）提供持续反馈

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

　　当团队遇到障碍时，反馈是解决办法之一。我们是否曾经发布了一个并不非常符合客户期望的用户界面？让我们记录在一张任务卡上，提醒我们在下一个UI故事中与客户合作完成一个书面原型。

　　管理层在担心项目进展情况吗？可展示一幅包含每天编写、运行和通过测试的图片。同时展示全局的功能覆盖率，如测试矩阵。你感到难以保持构建版本（build）的稳定么？Lisa的团队将展示构建版本发布的剩余天数，以保证每一个人都重视按时完成用户故事。当这成为一种习惯，他们不再需要任何可视化的提示。

　　（2）为用户创造价值

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