敏捷测试的10条法则

敏捷测试人员的十条法则

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

1、敏捷测试人员的定义

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

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

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

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

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

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

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

基本要求就是敏捷测试人员和其他敏捷团队成员一样，乐于学习新技能和面对新挑战，不会仅仅局限于测试问题。这不只是测试人员的特征，所有敏捷团队人员都应具有。敏捷测试人员帮助开发人员和客户团队解决可能出现的任何问题。测试人员提供信息以帮助团队回顾和了解哪些方案有效、哪些无效。 创造力、接受新思想、乐于承担任何任务或角色、重视客户和持续关注全局只是敏捷测试思想的组成部分。优秀的测试人员都有一种直觉和理解力：软件可能在何处失败？因为什么失败？

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

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

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

我们认为以下法则对敏捷测试人员非常重要： ● 提供持续反馈 ● 为客户创造价值 ● 进行面对面的沟通 ● 勇气 ● 简单化 ● 持续改进 ● 响应变化 ● 自我组织 ● 关注人 ● 享受乐趣 （1）提供持续反馈

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

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

管理层在担心项目进展情况吗？可展示一幅包含每天编写、运行和通过测试的图片。同时展示全局的功能覆盖率，如测试矩阵。你感到难以保持构建版本（build）的稳定么？Lisa的团队将展示构建版本发布

的剩余天数，以保证每一个人都重视按时完成用户故事。当这成为一种习惯，他们不再需要任何可视化的提示。

（2）为用户创造价值

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

----------------------------------------------------------------------------------------------------------------------------------------------------

Lisa的故事

我们的产品负责人在每一个迭代之前都参加过规划会议。尽管如此，在迭代开始并且我们讨论了故事的更多细节以及如何测试之后，他经常提出计划之外的想法。例如，“如果这个报表的选项能够包括X、Y和Z，并且能够存储到A上，那就非常完美了。”一个简单的请求可能会对一个故事增加很大的复杂度。我经常找来一名开发人员讨论这种添加是否能在计划之内的故事范围内解决。如果不能，我们会要求产品负责人写一张卡片用于下一次迭代。

—— Lisa

----------------------------------------------------------------------------------------------------------------------------------------------------

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

需的价值。

----------------------------------------------------------------------------------------------------------------------------------------------------

Lisa的故事

为了确保每次迭代都能创造价值，团队研究每一个故事以确定必要功能的“关键路径”或者“边边角角”。首先，我们完成核心任务，然后再补充功能的剩余部分。我们至少会发布核心功能。这总比一无所有或者只是到半成品要好。

—— Lisa

----------------------------------------------------------------------------------------------------------------------------------------------------

敏捷测试人员采取了与Lisa相同的方法。虽然我们的技能之一是识别“常用路径”以外的测试用例，但是我们仍然需要首先确保“常用路径”运转正常。我们自动化常用路径的测试，稍后增加负面测试和边界测试。持续关注对客户最有价值的东西，充分了解具体情境。如果一个应用关注安全性，则增加负面测试是必要的。在评估阶段，我们需要考虑测试时间以保证在迭代中安排足够的时间发布安全可靠的应用。 （3）进行面对面的沟通

一个团队如果沟通不好则难以协作。如今，许多团队分布于多个地理位置，沟通变得更加重要和富有挑战性。敏捷测试人员应该尽力促进沟通。这是把工作做好的关键因素。

----------------------------------------------------------------------------------------------------------------------------------------------------

Janet的故事

我曾经在一个团队工作，当时开发人员只与产品负责人交流，而把测试人员排除在外。他们随后才寻求了一些改变。开发人员不与测试人员坐在一起讨论的部分原因在于制度问题。另一个原因是历史问题。测试团队是一个新队伍，产品负责人已经习惯了直接联系开发人员。

我在团队里提出了这个问题，大家建立了一个规则。我们发现“三方协作的力量”获得了巨大成功。这意味着所有关于一项功能的讨论都需要开发人员、测试人员和产品负责人的参与。每一个人都有责任确保“三方协作”。如果有人发现另外两个人在交谈，他有权利加入。很快这变成了惯例，再也没有人想把测试人员置于讨论之外。这种做法使团队找到了解决所有问题的办法。

—— Janet

----------------------------------------------------------------------------------------------------------------------------------------------------

每当讨论一项功能如何运转或者一个接口应该如何定义时，测试人员都可以与开发人员和业务专家讨论。测试人员绝不应该阻碍一切客户和开发人员之间的沟通，他们要确保沟通是有效的。

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

本文来源：https://www.bwwdw.com/article/apkd.html