专访《更敏捷的测试》作者 Janet Gregory 和 Lisa Crispin

2009 年 Lisa Crispin 和 Janet Gregory 出版了一本书，书名为《敏捷的测试》。在2014 年又出版了一本《更敏捷的测试》，这本书真实地反映了这五年间在敏捷测试领域的发展。它包括测试和测试实践的新挑战，并讲了很多来自于世界各地的关于敏捷测试的实践案例。

你可以点击阅读《更敏捷的测试》的其中一章内容，对这本书有个初步的印象。

InfoQ 有幸对《更敏捷的测试》这本书的作者 Janet Gregory 和 Lisa Crispin 进行了访谈。

InfoQ：有些读者已经读过你们写得上一本书了，针对这些读者，你能解释一下《更敏捷测试》这本书与上一本书之间的关系吗？这个关于敏捷测试的第二本书涵盖了哪些内容呢？

Janet和Lisa：我们的编辑问过我们，是不是乐意去做关于敏捷测试的第二版呢？我们看了看第一版，觉得里面的内容仍然很实用，不需要做什么更新。与此同时，第一本书是 2008 年写的，截止今日我们又学习了很多东西。另外呢，技术也经历了变革和发展，所以又有了很多新的挑战。有句话说得好，那就是“路漫漫其修远兮”，最近六年间我们看到了许多敏捷团队奋斗的事迹，这些事迹在这本新书均有所记述，在第一本书中涉及过的主题会在这本新书中做更加详尽的阐述。

我们所写的这本《更敏捷的测试》希望能够独立于《敏捷的测试》进行阅读。然而，我们也不希望去重复第一本书中讲过的内容，所以我们为读者作了参考资料以便回顾特定的主题。

InfoQ：你能谈谈当前测试不得不面对的一些挑战吗？

Lisa：自从写第一本书以来，我认为最大的挑战就是交付团队可以并且应该帮助客户识别那些将为企业带来最大价值的特性，并且把它们切分成最小的可运行单元。Gojko Adzic 和 David Evan 从事的工作是以质量可视化、影响地图和其他的一些方式去帮助客户，帮助他们判定什么特性有最佳的投资回报率，而这对我们的工作有很大的影响。

Janet：我想，测试作为一项技能，有时会在团队中迷失，这些团队不考虑自身的情况下盲目地采取行动。我看到大型组织转向敏捷的同时，也希望他们的外包测试团队能够跟得上开发。我看到小型团队说我们再也不需要测试人员了，不需要他们去考虑各种不同的测试了。测试人员（或者测试）如何融入到流程中呢？这仍然有很多的问题。

InfoQ：许多人为这本书贡献了自己的经验。写这本书的时候你是怎么让他们参与进来的呢？

Janet：我们用了各种不同的方式。有些贡献者，在开会时或者交流时我们已经听说过他们的事迹，并认为它是值得分享的，所以我们会针对他们的故事问些具体的问题。还有一些贡献者，我们知道他们在某个领域很有经验，我们就会征求他们的意见，可不可以为我们写点东西呢？

Lisa：我来补充一下 Janet 所说的，我们由衷地感谢请教过的每个人，他们都很乐意把自己的故事分享到我们的书里。这些年来在会议上和 Twitter 上我们见识到了许多令人惊奇的实践，“网络”真是帮了我们的大忙了。我们还把 Twitter 上有关测试具体类型的辩论放到了一个边栏里。

在我们写这本书的过程中，很多的边栏内容贡献者还审校了我们的初稿，给我们提了很多非常有价值的建议。我想，他们肯定和我们一样，想帮助其他从业者学习和进步。

InfoQ：你们说，发现一种由角色和头衔向职业能力素养转变的趋势。那么你们觉得这会对测试行业有怎样的影响呢？

Lisa：我想，软件产品质量是构建出来的，你所说的这种转变会使每个团队成员变得更好。作为测试人员，如果我们向其他角色的同事学习，就可以带来更多的价值。而且随着我们的队友具备了更多的测试意识，他们就会想方设法交付更好的产品。我目前的队友对探索性测试的开展很有帮助，他们努力想办法排除那些我们捉摸不透的缺陷。我们测试人员就有时间去做那些更有价值的事了。

Janet：就像我之前所说，这件事很有挑战性。如果你的头衔是“测试人员”，那么组织就会把你摆到那个位置上。如果你的角色是具有测试或编程的专长的开发人员，那么定位就有点模糊了，大家会觉得不大适应。我个人觉得这种转变是个好事，因为它帮测试人员远离了“只能做好测试”的禁锢。测试这项技能不仅可以用于测试本身，还可以用于许多领域，比如充实和明确需求时就能派上用场。

InfoQ：在你的书中，你描述了“思维能力”。你能解释一下它们是什么吗？为什么它们这么重要？

Lisa：这个问题很难一句两句说清楚，所以我们在这本新书中花了整整一章去讨论思维能力！依照我们的经验来看，最好一支团队作为一个整体去从事测试和质量方面的工作。这需要人际关系的技巧、理解产品的能力，以及同从事不同工作的不同角色的人进行协作的能力。问题的解决、批判性的思维、横向的思维、时间的管理和其他所谓的“软”能力对于测试来说都是必不可少的。如果我们能够把这些能力传授给其他的团队成员，我们就会获得更好的胜机。

Janet：思维能力的意思是质疑现状——测试人员比较擅长这一点。因为测试人员在敏捷团队中必须扮演多种角色，这就需要他们忘记传统的测试人员的角色，在传统角色中测试就是负责执行测试。他们需要成为领导者、测试主管、测试分析师、测试自动化工程师，以及乐衷于探索研究的人。

InfoQ：在你们这本《更敏捷的测试》的书中，你们更新了敏捷测试的象限。你们可以说一说做了哪些改变么？为什么要做这些改变？

Janet：这个象限是我们要执行的测试类型的可视化模型。我们最新的版本只做了一些微小的调整。我想最重要的是要理解其他人是如何按照自己的需要来灵活使用的。在这本书中，我们收录了很多种人们为了满足当前的需要而对它做出的调整。为使它们能够更易于理解还加了文字的描述。

Lisa：我们收到了非常多有关于象限的正向反馈。人们告诉我们说，他们在团队工作区把象限海报挂到了墙上，或者在召开计划会议时把复印件带到会议室里。另一方面，读者也向我们反馈了一些困惑，有些人不知道象限的目的是什么，如何去运用它们。

于是，我们调整了一些用词，使每个象限的目的能够更加的清晰。例如左手边有一栏被称为“团队支持”，在 Brian Marick 的敏捷测试矩阵的最初版本中它叫做“编程支持”，它正是以此变化而来的。后来，我们又把它改成了“指导开发”，这会使它更加清晰地说明了该栏的用途，说明这些测试能帮助我们了解要写哪些代码，以及评估正在写的代码是不是已经完成了。

InfoQ：你能举一些例子来说明一下敏捷团队如何应用探索性测试方法的吗？

Janet：我喜欢鼓励人们去使用不同的探索性测试方法。Bach 有一篇关于这项技术的论文，大多数人通过阅读这篇论文也都能很好地理解这项基于交流的测试。大家正在用基于线索的测试进行实践，这种方法可以更加灵活地进行探索。

Lisa：Elisabeth Hendrickson 的一篇论文《探索它！》中有一个模版，在我自己的团队里测试人员用这个模版针对新功能或主要升级编写探索性测试章程。当一批故事通过了评审，并觉得时机差不多了，就由两个或三个程序员按照这个章程结对来开展工作。这个章程给他们规定了要测试的具体领域或方面，不过分约束他们自己的探索。他们向测试人员询问必要的问题。他们经常惊叹测试人员怎么能够发现那么多的问题，而这在他们持续编码的过程中对他们是有所帮助的。我们也偶尔也做“集体拥抱”的活动，活动会规定时间限制，活动中几个人甚至有时是整个团队会一起待在一间房子里或者通过视频会议聚在一起，有时会使用章程，有时只是普通地“找找缺陷”。

我听说开发团队做测试道场一起来学习更多有关测试的技术。我喜欢和我自己的团队一起去实践，尝试其他的技术，比如这种基于交流的测试技术。我鼓励所有团队去实践、探索不同的方法。它未必会花费你太多的时间。

InfoQ：敏捷团队能够通过探索性测试获得什么收益呢？

Lisa：功能探索的理念甚至还要早于编码，使用类似于纸面原型的简单技术，把想法画在白板上帮助自己的团队更好地交流和理解。业务专家经常在亲眼看到实物之前都不知道他们自己真正需要什么，这些活动有助于梳理思路，并分解成最小的单元去开始编码，然后下一步获取反馈意见。开发人员使用探索性测试能够帮助他们拓展自己的思维过程，在过程中会更多针对质量方面进行考虑。在我的经验中，这会帮助他们创建出更易于测试且更加健壮的代码。这也能鼓励他们与客户做更多的交流，这样做下去我们就能够掌握更多的信息。

InfoQ：随着测试自动化的逐渐增长，在测试代码和框架中的技术债会产生一定的风险。测试人员要如何处理这些风险呢？你们可以给一些建议吗？

Lisa：自动化测试根本就不是什么“捷径”，如果欠了债就很难还得清。但随着日积月累，错误的自动化方式会大幅降低团队的效率。我是以一名程序员的身份开始的软件生涯，我一直都很享受自动化测试。然而，作为一个测试人员，我通常要“牺牲”百分之二十的时间去编写测试代码。我从来都没打算能像我的程序员同事一样擅长设计出可维护性的代码。在我的经验里，测试人员（擅长测试用例的规格化）和程序员（擅长代码的设计）之间紧密协作，是从各种测试自动化层次中找出具有最佳的投资回报率的最好方式。

Janet：Lisa 讨论了实际执行测试规格化时测试人员和开发人员之间的协作。协作还有一个好处，那就是大家可以共同讨论不同层次下的自动化发生覆盖重叠或者覆盖缺失的可能性。我发现这种讨论对我们如何来设计自动化测试有非常大的影响。

InfoQ：企业内大型敏捷给测试带来了挑战。大型敏捷的测试怎么做？

Lisa：大型组织向敏捷转型时，我看到了这样一个挑战，他们从角色的烟囱（例如质量保证、编程、业务分析等）变成了团队烟囱。他们具有跨职能的团队，但是每个团队都是根据要做的事作为一个整体从上到下统一重新定义了的。为了激励团队去分享如何应对各种测试挑战，可以考虑采用建立一个测试实践社区这样的方式，这就和分享技术和工具一样。可以增加额外的角色去引导这些社区，并在执行层支持测试活动。

跨整个组织的持续集成（如果想要朝着持续交付努力的话）也是有必要的。大型公司通常都有一些需要在一起运行的大型系统。一个团队引入的缺陷经常会阻碍另一个团队的工作。

大型公司的交付团队可能和业务代表以及最终用户之间离得很远，所以想和他们协作会很困难。在与客户交流做业务分析时，保持一致的语言方式（比如 Planguage）会有助于功能行为和质量属性的规格化。

Janet：毫无疑问，大型敏捷很困难。这需要团队间的交流，Lisa 刚才提到的“烟囱”会成为一个很现实的问题。仔细考虑每次交流的相关性可以有效地消解这种孤立性。

InfoQ**：人们会越来越多地使用到连接在互联网上的不同设备。这就需要不同的测试关注点和测试方法，就像Gerie Owen在《物联网的测试：人类经验》中所说的那样。你们觉得物联网会对测试有怎样的冲击？**

Lisa：我读过 Gerie 的文章，但是我不太了解人类经验测试，所以我也不知道它会对测试有怎样的冲击。我们这些年一直在用角色模型，它们可以帮助我们思考人们将如何使用产品。在最近几年，我发现诸如影响地图和故事地图等技术能够帮助客户专注于软件的目的、他们想要解决的问题和需要交付给他们的价值。目前软件已经越来越多地嵌入到了我们日常使用的产品中，所以我想 Gerie 对这些技术的推动有着很重大的意义。

InfoQ：你觉得未来还会给测试人员带来什么变化吗？测试专业人士应该怎么武装自己？

Janet：持续不断地学习。多参加会议，看看最近发生了什么。关注你周围的世界，包括你的组织正在关注什么。没有人可以预测未来，但是我们可以有所察觉，并做好准备。

Lisa：我最近读了一篇文章，这篇文章指出最重要是要学会如何去学习和改进。公司需要鼓励学习的文化，让软件专业人员管理他们自己的工作量分配，包括要学习的时间。我们也需要用自己的时间去学习。我们有很多的学习途径，学习可不仅仅是指新的工具或者技术。我发现有些测试人员学了些其他的领域，比如哲学和心理学。我们还可以从其他的角色和部门那里学到些东西。比如，销售和市场营销人员能教我们很多与当前客户和潜在客户相关的知识。我们必须有一个平稳的工作效率，以便我们能够保持对工作的热情。

关于作者

Lisa Crispin与 Janet Gregory 一起合著了这本《更敏捷的测试：整个团队的学习之旅》（Addison-Wesley 2014 年出版），还合著了《敏捷测试：测试人员和敏捷团队实践指南》（Addison-Wesley 2009 年出版），还和 Tip House 合著了《极限测试》（Addison-Wesley 2002 年出版），并为由 Dorothy Graham 和 Mark Fewster 合著的《测试自动化经验》（Addison-Wesley 2011 年出版）以及《测试之美》贡献了自己的经验（O’Reilly 2009 年出版）。在同行们 2012 年敏捷测试日的投票中，Lisa 成为了最具影响力的敏捷测试专业人士。她非常享受在优秀的敏捷团队中作为一个测试人员的工作。她以写作、演讲、教学等方式分析她的个人经验，并参加了世界各地很多敏捷测试的交流。要更多地了解她，请点击此处，或者在Twitter 关注她@lisacrispin。

Janet Gregory是一名敏捷测试教练，以及 DragonFire 股份有限公司的流程顾问。她和 Lisa Crispin 一起合著了这本《更敏捷的测试：整个团队的学习之旅》（Addison-Wesley 2014 年出版），还合著了《敏捷测试：测试人员和敏捷团队实践指南》（Addison-Wesley 2009 年出版）。她还是《每个程序员应该知道的九十七件事》这本书的贡献者。她专门研究在敏捷团队中测试人员除了挑产品的毛病之外如何增加价值。例如，指导开发人员做面向业务的测试。Janet 和团队一起转向敏捷开发，并在世界各地传授敏捷测试的课程和教程。她经常给像《更好的软件》、《软件测试和绩效管理》和《敏捷之旅》等杂志投稿，并且很乐于在世界各地会议上和用户小组会议上分享她的经验。要更多地了解她，请点击此处。你也可以在twitter 上关注她@janetgregoryca。

编者按：即将于4 月23 日~25 日在北京国际会议中心举行的QCon 全球软件开发大会，将邀请本文作者

Ben Linders 做主题演讲，敬请期待。

查看英文原文： Q&A with Janet Gregory and Lisa Crispin about More Agile Testing