敏捷测试的10条法则.docx

敏捷测试的10条法则.docx

《敏捷测试的10条法则.docx》由会员分享，可在线阅读，更多相关《敏捷测试的10条法则.docx（11页珍藏版）》请在冰豆网上搜索。

敏捷测试的10条法则

敏捷测试人员的十条法则

　　敏捷团队里的每一个人都是一名测试人员，任何人都可能承担测试任务。

如果这种说法是正确的话，那么对于一名敏捷测试人员来说有什么特别之处吗？

如果我把自己看做是敏捷团队的测试人员，这到底意味着什么？

敏捷测试人员相比传统团队里的测试人员需要不同的技能吗？

有什么日常工作指南吗？

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

　　1、敏捷测试人员的定义

　　我们这样定义敏捷测试人员：

专业的测试人员，适应变化，与技术人员和业务人员展开良好协作，并理解利用测试记录需求和驱动开发的思想。

敏捷测试人员往往具有优秀的技术能力，知道如何与他人合作以实现自动化测试，同时也擅长探索性测试。

他们希望了解客户在做什么，以此更好地理解客户的软件需求。

　　谁是敏捷测试人员？

她是驱动敏捷测试的团队成员。

我们知道许多敏捷测试人员刚开始的时候在从事其他工作。

开发人员可能会爱上测试而超越单元测试的范畴。

习惯以敏捷方式工作的探索型测试人员也会被敏捷团队吸引。

其他角色的专业人士，比如业务或者功能分析师，也可能具有同样的特质并做同样的工作。

　　技能很重要，但态度更值得关注。

Janet总是说：

“如果态度不好，那么技能则一无是处”。

既然我们要为敏捷团队招募大量的测试人员，那么必须慎重考虑这一点，并与敏捷社区的其他朋友进行相关讨论。

测试人员往往可以总览全局。

他们更多时候是以客户的角度看待应用程序，这意味着他们一般以客户为中心。

　　2、敏捷测试思想

　　如何使一个团队变得“敏捷”？

对我们而言，敏捷团队持续关注如何最出色地工作并发布最优秀的产品。

根据我们的经验，这需要大量的训练、学习、时间、实验和协同工作。

这并不适合所有人，但是对那些希望自己团队充满活力并关注持续改进的人来说非常适合。

　　成功的项目总是因为优秀的人才完成了出色的工作。

在敏捷团队中做一名成功的测试人员所需要的特质可能与在任何团队做一名高水平的测试人员所需要的相同。

　　敏捷测试人员不会把自己看作是质量管理办公室的主管以保护客户避免受到缺陷代码的伤害。

她会乐于收集和分享信息，与客户或者产品负责人协作以帮助他们充分展示自己的需求，从而得到他们需要的功能，同时向所有人提供项目进展的反馈。

　　敏捷测试人员，可能包括其他拥有正确技能和思想的测试人员，都在不断想办法使团队能够更好地开发高质量的软件。

对个人来说，这可能意味着需要出席本地用户组会议或者圆桌会议看看其他团队在做什么，同时寻找新的工具以帮助团队通过测试描述、执行和自动化用户需求。

　　基本要求就是敏捷测试人员和其他敏捷团队成员一样，乐于学习新技能和面对新挑战，不会仅仅局限于测试问题。

这不只是测试人员的特征，所有敏捷团队人员都应具有。

敏捷测试人员帮助开发人员和客户团队解决可能出现的任何问题。

测试人员提供信息以帮助团队回顾和了解哪些方案有效、哪些无效。

　　创造力、接受新思想、乐于承担任何任务或角色、重视客户和持续关注全局只是敏捷测试思想的组成部分。

优秀的测试人员都有一种直觉和理解力：

软件可能在何处失败？

因为什么失败？

　　测试人员可能在测试领域拥有特殊的技能和经验，但是一名优秀的测试人员并不惧怕参与一场设计讨论，提供有助于测试性或者构建更良好方案的建议。

敏捷测试思想是面向结果的、技术性的、协作的、乐于学习的、勇于不断生产业务价值的。

3、应用敏捷法则和价值

　　个人能够对项目的成功产生巨大的影响。

我们当然认为拥有丰富经验、优良技能的成员的团队会强于人员素质较差的团队。

但是，一个团队不仅仅是个人成员的集合。

敏捷价值和准则强调的是对参与项目人员的关注和他们如何交互和沟通。

应用敏捷法则和价值的团队比拥有众多人才的运作较差的团队具有更高的团队意识和效率。

　　我们在本章开始展示了敏捷宣言中的4条价值声明，阐述了其偏爱的思想，但这不是最终判决，并没有说明应该怎么做，不应该怎么做。

敏捷宣言还包括了一系列进行软件开发的法则。

我们的敏捷“测试”法则部分继承于它们。

因为我们都是来源于极限编程文化，所以已经采用了很多其中的价值和基础法则。

我们也会结合自身团队总结的规则和指南。

当选择了工作的方式并做出决定之后，团队的价值观和法则将会指引具体工作。

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

　　●提供持续反馈

　　●为客户创造价值

　　●进行面对面的沟通

　　●勇气

　　●简单化

　　●持续改进

　　●响应变化

　　●自我组织

　　●关注人

　　●享受乐趣

（1）提供持续反馈

　　既然是测试驱动敏捷项目，那么很显然反馈在敏捷团队中占据重要的地位。

测试人员的传统角色就是“信息提供者”，这使得她天生就对敏捷团队很有价值。

敏捷测试人员的最大贡献之一是帮助产品负责人或者客户采用实例和测试的形式描述清楚每一个用户故事的需求。

然后，测试人员与团队同事将这些需求转化为可执行的测试。

测试人员、开发人员和其他团队成员尽快运行这些测试，并不断接收有价值的反馈。

我们将在本书中花费大量精力解释为何要这样做。

　　当团队遇到障碍时，反馈是解决办法之一。

我们是否曾经发布了一个并不非常符合客户期望的用户界面？

让我们记录在一张任务卡上，提醒我们在下一个UI故事中与客户合作完成一个书面原型。

　　管理层在担心项目进展情况吗？

可展示一幅包含每天编写、运行和通过测试的图片。

同时展示全局的功能覆盖率，如测试矩阵。

你感到难以保持构建版本（build）的稳定么？

Lisa的团队将展示构建版本发布的剩余天数，以保证每一个人都重视按时完成用户故事。

当这成为一种习惯，他们不再需要任何可视化的提示。

（2）为用户创造价值

　　敏捷开发就是在较低的版本发布中提供客户目前最迫切需要的功能。

这通常意味着限定范围。

我们经常在客户团队中遇到较酷功能的需求。

任何人都可以质疑这些内容，但是测试人员会判断其对故事的影响，因为他们需要考虑测试后果。

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

　　Lisa的故事

　　我们的产品负责人在每一个迭代之前都参加过规划会议。

尽管如此，在迭代开始并且我们讨论了故事的更多细节以及如何测试之后，他经常提出计划之外的想法。

例如，“如果这个报表的选项能够包括X、Y和Z，并且能够存储到A上，那就非常完美了。

”一个简单的请求可能会对一个故事增加很大的复杂度。

我经常找来一名开发人员讨论这种添加是否能在计划之内的故事范围内解决。

如果不能，我们会要求产品负责人写一张卡片用于下一次迭代。

　　——Lisa

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

　　敏捷测试人员需要总览全局。

我们可以在当前迭代中发布最重要的功能，稍后再完善。

如果让新功能偷偷混进来，就会面临一无所获的风险。

如果过于关注边边角角，而忽略了核心功能，就无法提供业务所需的价值。

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

　　Lisa的故事

　　为了确保每次迭代都能创造价值，团队研究每一个故事以确定必要功能的“关键路径”或者“边边角角”。

首先，我们完成核心任务，然后再补充功能的剩余部分。

我们至少会发布核心功能。

这总比一无所有或者只是到半成品要好。

　　——Lisa

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

　　敏捷测试人员采取了与Lisa相同的方法。

虽然我们的技能之一是识别“常用路径”以外的测试用例，但是我们仍然需要首先确保“常用路径”运转正常。

我们自动化常用路径的测试，稍后增加负面测试和边界测试。

持续关注对客户最有价值的东西，充分了解具体情境。

如果一个应用关注安全性，则增加负面测试是必要的。

在评估阶段，我们需要考虑测试时间以保证在迭代中安排足够的时间发布安全可靠的应用。

（3）进行面对面的沟通

　　一个团队如果沟通不好则难以协作。

如今，许多团队分布于多个地理位置，沟通变得更加重要和富有挑战性。

敏捷测试人员应该尽力促进沟通。

这是把工作做好的关键因素。

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

　　Janet的故事

　　我曾经在一个团队工作，当时开发人员只与产品负责人交流，而把测试人员排除在外。

他们随后才寻求了一些改变。

开发人员不与测试人员坐在一起讨论的部分原因在于制度问题。

另一个原因是历史问题。

测试团队是一个新队伍，产品负责人已经习惯了直接联系开发人员。

　　我在团队里提出了这个问题，大家建立了一个规则。

我们发现“三方协作的力量”获得了巨大成功。

这意味着所有关于一项功能的讨论都需要开发人员、测试人员和产品负责人的参与。

每一个人都有责任确保“三方协作”。

如果有人发现另外两个人在交谈，他有权利加入。

很快这变成了惯例，再也没有人想把测试人员置于讨论之外。

这种做法使团队找到了解决所有问题的办法。

　　——Janet

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

　　每当讨论一项功能如何运转或者一个接口应该如何定义时，测试人员都可以与开发人员和业务专家讨论。

测试人员绝不应该阻碍一切客户和开发人员之间的沟通，他们要确保沟通是有效的。

　　敏捷测试人员从客户的角度思考每一个故事，但是也理解实现功能相关的技术和局限性。

他们可以帮助客户和开发人员达成共识。

业务人员和软件人员经常使用不同的语言。

他们不得不找到一些共同点来展开协作。

测试人员可以帮助他们拥有一种共通语言。

　　BrianMarick（2004）提倡我们应该使用实例来定义这种语言。

当Lisa的团队在sprint规划会议中偏离主题成为哲学讨论时，Lisa要求产品负责人提供一个示例或者使用场景。

测试人员能够通过更多的示例活跃讨论。

这有助于客户更清晰地设想他们的需求。

测试人员也会帮助开发人员编写精心设计的代码以满足需求。

？

　　面对面的沟通是不可替代的。

敏捷开发依赖于持续的合作。

就像其他敏捷团队成员一样，从事测试工作的人会不断寻找客户和技术团队成员来讨论和合作。

当敏捷测试人员对某个隐藏的假设或者误解的需求产生怀疑时，她会与客户和开发人员讨论。

如果处于不同地点的人需要交谈，他们会试图寻找创造性的方式替代面对面、实时的交流。

　　（4）勇气

　　勇气是极限编程的核心价值，类似测试自动化和持续集成的方式允许团队实践这种价值。

开发人员有勇气修改和重构代码，因为他们拥有自动化回归测试集的安全保护。

在本节，我们将讨论敏捷团队转型中所需的勇气。

　　你是否曾经在这样的团队中工作：

测试人员固守于自己的领域，不与其他业务相关者和技术团队进行任何讨论。

虽然你找机会进入了协作的敏捷环境，可能会对找客户索要实例或者找开发人员帮忙自动化测试或者在每日例会时提出一个难题等感到不习惯。

　　当最初加入敏捷团队或者当前的团队开始过渡到敏捷开发模式时，通常你会产生恐惧感，并且存在大量的问题需要答案。

我们到底如何才能在如此短的时间内完成对每一个用户故事的测试任务？

测试如何跟上开发的节奏？

如何确定需要多少测试？

又或者你是功能测试经理或者质量过程经理，但不清楚在敏捷团队中如何定位自己的角色，也没人知道答案。

敏捷测试人员需要勇气找到这些问题的答案，但需要勇气的原因不仅限于此。

　　我们需要勇气允许自己失败，至少我们会有短暂性失败，我们要从失败中学习教训。

在由于构建版本不稳定导致一次迭代失败之后，我们要开始寻找方法以确保这种事情不再发生。

　　我们需要勇气允许其他人犯错误，因为这是汲取教训的唯一途径。

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

　　Lisa的故事

　　我曾经参与过一个项目，当时的敏捷指导员坚持我应该呆在独立的测试团队里（通常只有一个人），其中的工作不包含在开发人员的跟踪和进度中。

我不得不尝试一下。

在项目由于测试没有完成遭遇麻烦之后，我询问敏捷指导员是否可以按照我希望的测试方式尝试一个或两个迭代。

团队整体运作的方式是非常令人满意。

在迭代结束之前每一个用户故事都被做了测试（并实现），客户对此结果更加满意。

　　——Lisa

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

　　我们需要勇气寻求帮助，特别是当能够提供帮助的人看起来特别忙碌的时候。

抛弃旧的制度，加入一个关乎项目成功与否的团队也需要勇气。

提出问题或者指出你的想法存在缺陷需要勇气，即使是在遵循敏捷价值和原则的团队中。

不要害怕，敏捷团队是开放的，通常都会接受新观念。

（5）简单化

　　KentBeck的ExtremeProgrammingExplained（《极限编程解析》）建议我们尽可能做最简单的、有用的事情。

这并不意味着你最先尝试的事情必须有用，但应该是最简单的。

　　敏捷测试人员和他们的团队面临的挑战不仅是生产最简单的有效软件而且还需要采取简单的方法以确保软件符合客户需求。

这并不意味着团队不应该花时间分析主题和故事、思考合适的架构和设计。

而是说，当业务部门的需求比较复杂的时候，团队可能需要将方案退回给他们，更简单的解决方案也会产生同样的价值。

　　我们中的某些人在软件公司以测试人员和质量保证人员的身份工作时，曾经被要求制定质量标准。

我们认为这是一种倒退，因为应该由客户团队来决定他们想要的质量水平。

测试人员和其他团队成员应该向客户提供信息并帮助他们全面考虑质量问题，包括非功能性需求，如性能和安全。

最终决定由客户拍板。

团队能够通过简单、逐步的方法帮助客户做出高质量的决定。

敏捷测试意味着通过最简单的测试验证某项功能存在或者已经达到客户的质量标准（如性能）。

　　简单并不意味着容易。

对于测试人员来说，这意味着采用能够找到的最轻量级的工具和技术恰到好处地测试。

工具可以简单到只是一张电子表格或者清单。

需要自动化回归测试，但是应该把它们分解到最底层以获取快速反馈。

甚至简单的冒烟测试也可能满足面向业务的测试自动化。

　　探索性测试能够用来了解应用程序和发现深藏的缺陷，但是应该从基本的、时间可控的测试开始，然后根据边界测试评估进展。

简单性帮助我们关注风险、投资回报和改善最痛苦的问题。

　　（6）持续改进

　　想办法把工作做得更出色是敏捷测试人员应牢记的。

当然，整个团队都应该具有这样的想法，因为敏捷的核心价值就是团队总是尝试更出色地工作。

测试人员应参加团队总结会，评估做得好的方面和需要加强和改变的方面。

测试人员把测试问题摆到整个团队中解决。

团队通过采取过程改进实践（如总结回顾和阻碍代办事项等）最大程度地改善测试和所有其他领域。

对于更严重的问题，团队一次只关注一到两个问题，以确保彻底解决了实际问题，而不只是做做表面文章。

　　敏捷测试人员和他们的团队总是在寻找工具、技能或者实践以帮助他们增加更多价值或者得到更好的客户投资回报。

敏捷开发的短期迭代更易于尝试新事物，以验证是否值得长期采用。

　　学习新技能和提高专业技能水平对敏捷测试人员非常重要。

可利用各种免费的资源提高专业技能，如探索性测试。

可参加各种会议，加入邮件列表，阅读文章、博客和书籍以获取新思想。

还要想办法自动化（或者从其他同事中获得帮助）平淡的或者重复性的工作，以此获得更多时间投入到宝贵的专业技能提升中。

　　Weyerhaeuser公司iLevel部门的软件质量保证负责人PierreVeragren指出了敏捷团队中经常见到的一种特点：

“AADD（AgileAttentionDeficitDisorder），即敏捷注意力缺乏症”。

任何无法快速学习的事物都可能被视为无用的。

敏捷团队成员讲究投资回报率，如果他们无法快速理解，他们就会转移目标。

当你每两周或者更短时间就要发布一个产品级的软件时，这个特点并不是缺陷。

　　总结回顾是一种重要的敏捷实践，让团队利用过去的经验把未来的工作做得更好。

敏捷测试人员利用这种机会提出与测试相关的问题并要求团队集思广益地去解决它。

这种方式使团队通过自我反馈来得到持续改进。

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

　　Lisa的故事

　　我们的团队曾经利用总结回顾会议获得了巨大的好处，但是我们认为需要一些新事物来帮助我们把工作做得更好。

我建议维护一份“阻碍待办事项”，记录下影响生产力的各种条目。

我写的第一条就是测试环境的响应时间缓慢。

系统管理员找来两台便宜的计算机，把它们变成快速的新服务器。

数据库管理员分析了测试数据库性能，发现单硬盘系统是个障碍，经理开了绿灯，安装了一个RAID以获取更好的硬盘访问性能。

很快，我们就能够快速地部署构建和进行探索性测试了。

　　—— Lisa

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

　　（7）响应变化

　　在瀑布开发模式中工作时，我们习惯说：

“抱歉，我们现在不能更改。

需求被冻结了。

我们将在下一个补丁包里做更改”。

客户对此非常失望，因为他们意识到无法实现当前所有的需求。

　　在为期两周的敏捷迭代中，我们可能会说：

“好的，先在卡片上记录下来，我们将在下一个迭代或者版本中实现”，但是客户知道他们可以获得想要的变化，因为他们可以控制优先级。

响应变化是敏捷实践的重要价值，但是我们发现这对测试人员来说却是最困难的概念之一。

测试人员渴望的是稳定，所以他们会说：

“我已经测试过了，任务完成了”。

持续的需求变化是测试人员的噩梦。

但是，作为一名敏捷测试人员，我们不得不拥抱变化。

周三，我们可能期望启动故事A和B，下周五做故事C。

但是到了周五，客户重新设定了优先级，现在需要故事A、X和Y。

只要我们持续与客户交流，我们就能处理这些变化，因为我们与团队的其他成员保持同步。

　　有些敏捷团队尝试提前准备下一次迭代，比如编写高层次的测试用例、捕捉业务满足条件或者记录示例。

如果故事的优先级发生变化则这种行为可能只是浪费时间。

但是，分布式团队非常需要额外的反馈周期为迭代做准备。

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

　　Lisa的故事

　　一个远程团队成员曾经是我们的现场经理。

他在帮助企业客户编写和设定故事优先级方面起到了关键作用。

他对编程和业务都有深刻理解，这有助于他提出创造性的解决方案以满足业务需求。

当他搬到印度时，我们设法留住他以发挥他的专长作用。

我们会定期安排与他开会，与产品负责人通过电话会议讨论未来的故事。

我们不得不在能使用的各种工具中切换（从低技术含量的索引卡到在线工具）。

　　因为团队乐于通过有效的方式做出改变，寻找工具以确保跟得上变化，所以我们能够使他的专长继续发挥作用。

　　——Lisa

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

　　某些团队的分析人员花费较多的时间与业务专家做提前规划。

每一个团队不得不在头脑风暴式的预先解决方案和每一次迭代的第一天从头开始之间寻找平衡。

敏捷测试人员与团队一起适应变化。

　　自动化测试是一个关键的解决方案。

有一件事情我们可以肯定：

如果只是手动测试，没有敏捷团队会获得成功。

我们需要健壮的自动化方案以在有效的时间内发挥价值。

　　（8）自我组织

　　敏捷测试人员是自组织敏捷团队的组成部分。

团队文化贯彻于敏捷测试理念。

当开发人员、系统管理员、分析员、数据库专家和客户团队持续关注测试和测试自动化，测试人员就会获得全新的视角。

自动化测试很困难，但是当整个团队都在为此努力时就会简单得多。

当大家具有多重技能和多层次视角时，任何测试问题都会更容易解决。

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

　　Lisa的故事

　　我的团队是一个自我组织的好示例。

当我们实施Scrum时，面对一个问题很多的遗留系统而且没有自动化测试。

对代码的任何更改都存在风险。

经理可能知道如何解决这个问题，但是他没有提出来。

相反，我们研究了一下并拟定了一个计划。

　　开发人员开始在新的可测试的架构中实现新故事，采取测试驱动开发的模式。

测试人员编写手动回归测试脚本，整个团队——开发人员、测试人员、系统管理员、数据库管理员——在每个迭代的最后两天执行。

与此同时，测试人员将执行用户界面的自动化冒烟回归测试。

最终，新代码的架构让我们可以通过某些工具（如FitNesse）自动化功能测试。

　　我们在起步阶段实施了这项计划，并在每次迭代中改进方法。

利用团队每一位成员的技能比我独断专行地决定自动化策略要好