3G Eden
RSS借Selenium诞生十周年庆典之机，来自于ThoughtWorker公司的几位专家共同推出了一本精选书，其中收录了他们在软件测试方法、工具和文化方面的一些文章。这本精选书以电子书的形式提供，书名为《展望敏捷软件测试》（Perspectives On Agile Software Testing），可以在ThoughtWorks的网站上进行免费下载。
本书的篇幅虽然简短，但包含的信息量却相当丰富，其中提到了测试工具的演变、在敏捷环境中的测试、对移动设备进行测试、对移动应用使用BDD及持续交付等等。本书中的某些部分很有看点，例如对不同工具的比较。虽然篇幅简短，但内容丰富，对移动设备的测试进行了深入的描述，包括持续集成与持续部署等概念。
Anand Bagmar首先介绍了Selenium这一工具及它的使用方式。2004年，Jason Huggins在对ThoughtWorks的一个内部应用程序进行测试时，创建了JavaScriptTestRunner工具，正是它改变了对基于浏览器的测试进行自动化的方式。该工具随后演变成了“Selenium”，并最终实现了开源。
Alabe Duarte和Fabio Maia介绍了移动测试方面的内容。在移动测试中常见的挑战包括测试内网延迟、3G/4G连接、WiFi以及与地理位置相关的特性。为了对web应用进行测试，并且保持单元测试的快速执行，他们会经常使用Test Double（替身）。这种技术有助于避免代码与任何进程或无法控制的外部依赖进行通信。这方面一个非常有趣的例子是Appium，它允许任何人为基于不同语言开发的移动应用编写测试。Appium能够实现这一点的原因在于它实现了Selenium的webdriver API，因此每种语言都可以通过webdriver与之进行连接。
Prateek Baheti和Vishnu karthik接下来介绍了在移动应用中进行BDD风格测试的方法。在BDD风格测试中，通过一种中立的、并且非常特定于具体领域的语言表达出测试的规格。BDD的实现需要工具的支持，通过工具将测试规格与底层的实现结合连接在一起。
作者举了一个例子，描述了某个消息发送应用的一个具体测试场景：
- 我要以foo@foo.com帐号登录
- 我对user@user.com发送了一条消息“Lorem ipsum dolor sit amet”（一段著名的用于测试排版的假文字）
- “user@user.com”会收到一条通知，告诉他有新的消息来了
以上这个测试不会与底层的细节打交道，而是以自然语言、使用领域术语描述了这一测试场景。在这个测试用例中，收到一条通知就是一个领域术语，而它的具体实现在不同的平台上可能是完全不同的。
Gayathri Mohan介绍了在移动应用中使用持续交付方面的内容。在这一章节中，她在对移动应用进行手动测试或自动化测试的上下文中对持续交付进行了阐述。她还对持续集成和跨平台自动测试框架进行了深入讲解。
InfoQ有幸与本书的作者们进行了一次访谈，话题涉及了本书的内容，以及测试方面的最佳实践。
InfoQ：对于读者来说，阅读这本书能学到什么新东西？
本书收集了一系列优秀的文章，它们从不同的维度对测试进行了讲解，包括——
Anand Bagmar在书中分析了Selenium是否已经成熟，使用Selenium实现自动化与测试自动化金字塔（Test Automation Pyramid）有怎样的关系。并且对这个时代的测试人员如何做好准备迎接未来的挑战提供了一些建议。
- Daniel Amorim分析了在敏捷环境中进行测试的各种不同维度。
- 有大量的内容是关于移动测试的
- 对移动设备进行不同类型的测试（Alabe Durate和Fabio Maia），
- 如何在移动应用中开展BDD风格的测试（Prateek Baheti和Vishnu Karthik），
- Gayathri Mohan将这一点更进一步，探讨了如何在应用程序中实现持续交付。
- Vikrant Chauhan和Sushant Chaudhary介绍了在移动测试中可能遇到的各种挑战。
- Nicholas Pufal和Juraci Vieira为读者分析了对BDD的误解。
- Paul Hammant介绍了如何聘用具备不同级别专业知识的Selenium QA人员。
InfoQ：你们在书中提到了测试金字塔反模式，能为我们详细解释一下吗？
自动化测试的目的在于为团队提供快速的反馈信息：最近的某次改动是否造成了原先能够正常运行的功能出现了故障？
Martin Fowler在他的博客帖子中对测试自动化金字塔进行了解释。
在理想的测试金字塔中，发生在最接近于源代码的地方的自动化测试数量应当最大话，例如在单元测试这一层，而发生在金字塔顶层的测试的自测数量应当最小话，例如在功能性UI（用户界面）层。此外，单元测试应当对产品代码中的细粒度的片段进行测试，而UI测试应当专注于对构建与部署后的产品进行业务功能方面的确认，例如对用户的访问过程和场景进行测试。不过，要实现并长期维持一个“良好”的金字塔，需要团队在流程和实践方面投入巨大的精力。
许多团队对于（各种类型的）自动化测试的投入依然有所不足。有些团队采取了某种快捷方式，在代码开发完成之后，设立一个独立的团队专门编写UI层的测试。而这种方式的结果是，团队对于金字塔底层的自动化测试方面的关注相当不足。而且，就如大家都意识到的一样，UI自动化的实现和运行都相当缓慢，并且非常容易被破坏，对于UI任何一点微小的改动都有可能造成测试失败。因此，尽管许多团队已经在UI自动化方面投入了许多资源，但他们还是要将大部分的精力投入到对UI测试的缺陷修复、更新以及维护上，并且需要专门安排一组测试人员手动地进行重复式的回归测试。这就形式了一种蛋筒式反模式（Ice-Cream Cone）（即倒金字塔形状）。
有些情况下，测试团队是整个组织中的一个独立团队，或者有可能将测试任务交给第三方或合作伙伴完成。他们对于产品的测试方式无法达到开发者之间那样的合作能力。开发者与测试者之间也不会对于哪些测试要进行自动化，哪些不需要自动化等方面进行交流。其结果是可能会产生开发者与测试者之间的测试用例产生了重复。而更严重的问题在于，在自动化测试中有可能会遗漏许多测试用例或测试场景。这是一种双向测试金字塔反模式。
Fabio Pereira用另外一种有趣的方式对双向测试金字塔反模式进行了描述，并将其称为纸杯蛋糕反模式（Cupcake）。他也提出了某些技术，可以通过使用这些技术让团队远离这些反模式，而实现理想的测试金字塔。
InfoQ：书中提到，QA的角色正在变得越来越复杂，他们需要进行心态上的转变，同时在技术方向上也要需求突破。请对这种说法表达一下你们的意见。
当团队开始使用敏捷开发方法之后，团队中的每位成员都需要加快他们工作的脚步。下面这张图来自于Agile QA Process，它表现了QA人员在每个迭代中需要经历的一系列活动。
在短小的迭代中，这一流程会显得非常紧张。此外，QA通常在这种工作方式中通常需要经历三个不同性质的阶段。
- 过去 —— 对于之前迭代中完成的工作提供支持。
- 现在——保证创建的特性是“正确”的，并且实现的方式也是“正确”的。
- 将来——对于下一阶段的开发中可能到来的任务做好准备，并且开始考虑如何对其进行测试。
最后，自动化测试对于保证团队取得成功是一项必不可少的要求，而为了让团队实现这一点，QA在其中扮演了十分重要的角色。这不仅要求QA具有优秀的手工测试和探索性测试技术，并且要求QA对于测试中的产品在技术方面也要有相当程度的理解，从而保证确定了正确的测试，并且在测试金字塔的正确环节实现自动化。
由于QA在这一流程中需要经历大量的活动，并且经历这些不同的阶段，因此他（或她）需要对工作的方式进行优化，并且做到对下一阶段必须要做的事持续不断地对优先级进行适当的调整。因此，QA这一角色变得更加复杂，为了取得成功，必须换一种不同的思考方式。
InfoQ：你对QA在三个不同维度中所扮演的角色：商业、技术与DevOps进行了很好的诠释。QA在这三个方面的不同角色有哪些相似之处和不同之处呢？
这三个维度的共同点在于，QA对于产品的质量和自动化测试必须具有主人翁意识，他们需要让团队专注于交付高质量的产品，确保它易于维护和实现新的特性。
这三种类型的QA之间也有一些不同之处：
- 在商业维度上的QA是由业务驱动的，并且需要很好的与客户交流的沟通技巧。他们将通过各种示例对产品规格有一个很好的了解，并且需要具有优秀的聆听技巧，以从客户那里获得所需的验收测试项目。
- 在技术维度上的QA具有优秀的编程技术，并成为自动化测试方面的专家。他们对关注代码的可维护性，总是寻求各种优秀的实践，例如整洁的代码、最佳实践和设计模式等等。这些QA会与开发者结对工作，共同创建解决方案。
- 在DevOps维度上的QA需要具备持续交付与对重复性任务进行自动化的知识。他们将帮助团队打造一个测试金字塔，以实现某种持续交付的周期。
InfoQ：本书介绍了Appium这门工具，它实现了Selenium webdriver API，专门用于移动测试。那么这个工具与其它类型的移动测试工作有什么不同呢？使用它能为我带来怎样的好处？
Appium的社区非常活跃。由于它的开源本质，有许多贡献都是来自于社区，这也使它能够更快地实现新的特性和修复缺陷。并且如果你需要在云端环境中运行你的测试，以实现更大的规模，Saucelabs服务同样也支持Appium。
并且由于它实现了标准自动化规格，因此可以很容易地找到一种以你所熟悉的语言编写的Selenium webdriver的具体实现。比方说，QA团队可以很容易地找到Java语言 (Android)或Objective-C语言 (iOS)以外的不同实现。
其它的好处还包括：
- 如果你的移动应用是跨平台的，那么你也能够在每个平台上都使用相同的测试。
- Appium能够对接近生产版本的应用进行测试，更妙的是，即使是你打算提交到marketplace上的版本，Appium同样可以进行测试。
InfoQ：对于持续集成和持续交付在移动应用开发中的重要性，你们是怎么看的？
在这个快节奏的社会中，作为商业组织，我们需要尽快地将产品和服务展现给用户，但是，如果产品本身质量不过关，那么仅仅做到快速推向市场也是不够的。持续集成（CI）和持续交付（CD）这样的实践能够让团队在将产品交付给客户时充满信心。
这些实践适用于基于Web的产品，同样也适用于基于移动的产品。区别仅在于使用的工具不同，并且需要对这些实践的各个部分进行微调，以确保得到最佳的结果。
InfoQ：在移动开发中使用BDD有什么好处呢？
BDD最大的好处在于，团队之间可以用相同的领域术语和业务术语进行交流，最终可以消除在项目干系人和团队成员之间产生的所有理解的歧义。
如果能够正确地使用BDD，那它就能够隐藏实现细节，并且帮助开发者专注于该特性或功能所试图解决的商业目标。
如果能够正确地使用BDD，它就能够隐藏特定于平台的细节。
*：就像其它任何工具一样，你必须正确地使用BDD，并且使用在适当的上下文中，这样才能够发挥出它的价值所在。
**：BDD意味着你在你的开发环境中又多加了一层额外的代码（和工具）。无论你添加了哪种类型的工具或流程，它都伴随着相应的成本。在你决定在开发周期中使用任何工具、技术和流程之前，都应该全面地了解它的所有优点与缺点。
InfoQ：对于敏捷QA来说，最关键的技术是什么？
除了必备的测试技能之外，以下技能（排名不分先后）对于QA在敏捷团队中获得成功也是相当重要的：
- 能够对不同的测试活动排列优先级的能力。
- 要将心态转变为：“帮助团队实现迭代中所包含的每个需求的‘完成定义（Definition of Done）’。”
- 与业务分析师或产品负责人进行协商，以探讨当前阶段需求的真实价值，以确保在短时间之内创建出“正确”的产品。
- 保持开放的心态 —— 这有助于你以一种更优的方式学习新的工作方法。
- 尽可能帮助团队在测试金字塔的底部实现自动化。
InfoQ：你们是否打算在不久的将来，在新书中涵盖更多有关敏捷和测试的概念。
我们对于下一本书已经有了许多点子，它将基于这本书中已经涵盖的内容。不过，我们也乐于倾听读者的意见，我们会尽量在下一本书中加入他们在反馈和建议中所提到的内容！
关于本书作者
Anand Bagmar是一位动手能力很强并且注重结果的软件质量福音传道师，在IT领域已经具有17年以上的经验。他创建了各种与软件测试相关的开源工具，包括WAAT（Web Analytics Automation Testing Framework）、TaaS（用于在不同系统间进行的集成测试进行自动化）以及TTA（Test Trend Analyzer）。
Daniel Amorim在ThoughtWorks担任敏捷顾问QA。他从2007年开始在IT领域开始工作，始终致力于提倡敏捷测试的最佳实践，并为开发团队作出贡献。
Alabê Duarte从2007年起在ThoughtWorks担任顾问开发者。
Fábio Maia是ThoughtWorks的一位高级开发顾问。他对于由Qt/C++或C#编写的桌面应用程序特别感兴趣，他也是一位使用C#/XNA的游戏开发者。
Prateek Baheti是ThoughtWorks的一位应用程序开发者，他参与Twist项目已经有两年的时间了。
Vishnu Karthik是ThoughtWorks的一位开发者。他曾经参与过Twist和自动化测试的项目。
Gayathri Mohan是一位ThoughtWorks的高级质量分析师，在公司里有超过5年的经验了。她的工作经历包括多个领域，例如旅行、零售、电子商务，以及多种平台，例如.NET、Rails、Android和iOS。
Vikrant Chauhan是一位技术狂热分子。他密切地关注开源测试工具的发展，并且总是在任何可能的情况下使用它们。
Sushant Choudhary是一位充满热情的技术爱好者，也是一位体育迷。考虑到不断变化的技术方案和它对社会的影响，他总是时刻进行探索，并且在软件工程中应用新的开发技术。
Nicholas Pufal从少年时代开始就对编程产生了浓厚的兴趣，当时他已经开始尝试编写开源代码项目了。他对于设计模式、优秀的开发实践，以及改善敏捷团队的沟通技巧和交付质量的各种方式保持着很高的热情。
Juraci Vieira也是一位技术狂热者，他的职业生涯开始于测试人员的岗位。他被自动化所深深吸引，然后才明白质量本身就是由软件产生的，从那之后，他摇身一变成为了一名热情洋溢的开发人员。
Paul Hammant已经40多岁了，他从2002开始就在ThoughtWorks担任首席顾问，1989年起就进行各种顾问工作。除了从客户那边赚钱之外，他也常常帮助ThoughtWorks进行各种开源活动。
查看英文原文：Perspectives On Agile Software Testing - Book Review
