3、应用敏捷法则和价值
个人能够对项目的成功产生巨大的影响。我们当然认为拥有丰富经验、优良技能的成员的团队会强于人员素质较差的团队。但是，一个团队不仅仅是个人成员的集合。敏捷价值和准则强调的是对参与项目人员的关注和他们如何交互和沟通。应用敏捷法则和价值的团队比拥有众多人才的运作较差的团队具有更高的团队意识和效率。
我们在本章开始展示了敏捷宣言中的4条价值声明，阐述了其偏爱的思想，但这不是最终判决，并没有说明应该怎么做，不应该怎么做。敏捷宣言还包括了一系列进行软件开发的法则。我们的敏捷“测试”法则部分继承于它们。因为我们都是来源于极限编程文化，所以已经采用了很多其中的价值和基础法则。我们也会结合自身团队总结的规则和指南。当选择了工作的方式并做出决定之后，团队的价值观和法则将会指引具体工作。
我们认为以下法则对敏捷测试人员非常重要：
● 提供持续反馈
● 为客户创造价值
● 进行面对面的沟通
● 勇气
● 简单化
● 持续改进
● 响应变化
● 自我组织
● 关注人
● 享受乐趣
（1）提供持续反馈
既然是测试驱动敏捷项目，那么很显然反馈在敏捷团队中占据重要的地位。测试人员的传统角色就是“信息提供者”，这使得她天生就对敏捷团队很有价值。敏捷测试人员的最大贡献之一是帮助产品负责人或者客户采用实例和测试的形式描述清楚每一个用户故事的需求。然后，测试人员与团队同事将这些需求转化为可执行的测试。测试人员、开发人员和其他团队成员尽快运行这些测试，并不断接收有价值的反馈。我们将在本书中花费大量精力解释为何要这样做。
当团队遇到障碍时，反馈是解决办法之一。我们是否曾经发布了一个并不非常符合客户期望的用户界面？让我们记录在一张任务卡上，提醒我们在下一个UI故事中与客户合作完成一个书面原型。
管理层在担心项目进展情况吗？可展示一幅包含每天编写、运行和通过测试的图片。同时展示全局的功能覆盖率，如测试矩阵。你感到难以保持构建版本（build）的稳定么？Lisa的团队将展示构建版本发布的剩余天数，以保证每一个人都重视按时完成用户故事。当这成为一种习惯，他们不再需要任何可视化的提示。
（2）为用户创造价值
敏捷开发就是在较低的版本发布中提供客户目前最迫切需要的功能。这通常意味着限定范围。我们经常在客户团队中遇到较酷功能的需求。任何人都可以质疑这些内容，但是测试人员会判断其对故事的影响，因为他们需要考虑测试后果。
----------------------------------------------------------------------------------------------------------------------------------------------------
Lisa的故事
我们的产品负责人在每一个迭代之前都参加过规划会议。尽管如此，在迭代开始并且我们讨论了故事的更多细节以及如何测试之后，他经常提出计划之外的想法。例如，“如果这个报表的选项能够包括X、Y和Z，并且能够存储到A上，那就非常完美了。”一个简单的请求可能会对一个故事增加很大的复杂度。我经常找来一名开发人员讨论这种添加是否能在计划之内的故事范围内解决。如果不能，我们会要求产品负责人写一张卡片用于下一次迭代。
—— Lisa
----------------------------------------------------------------------------------------------------------------------------------------------------
敏捷测试人员需要总览全局。我们可以在当前迭代中发布最重要的功能，稍后再完善。如果让新功能偷偷混进来，就会面临一无所获的风险。如果过于关注边边角角，而忽略了核心功能，就无法提供业务所需的价值。
----------------------------------------------------------------------------------------------------------------------------------------------------
Lisa的故事
为了确保每次迭代都能创造价值，团队研究每一个故事以确定必要功能的“关键路径”或者“边边角角”。首先，我们完成核心任务，然后再补充功能的剩余部分。我们至少会发布核心功能。这总比一无所有或者只是到半成品要好。
—— Lisa
----------------------------------------------------------------------------------------------------------------------------------------------------
敏捷测试人员采取了与Lisa相同的方法。虽然我们的技能之一是识别“常用路径”以外的测试用例，但是我们仍然需要首先确保“常用路径”运转正常。我们自动化常用路径的测试，稍后增加负面测试和边界测试。持续关注对客户最有价值的东西，充分了解具体情境。如果一个应用关注安全性，则增加负面测试是必要的。在评估阶段，我们需要考虑测试时间以保证在迭代中安排足够的时间发布安全可靠的应用。
