Lisa Crisplin 访谈：测试的现状与未来

本文要点

• 测试想要成功向敏捷转型，管理层必须要参与进来，他们需要理解敏捷对测试的意义并且支持敏捷测试。

• 在敏捷开发中我们仍然需要专家。所不同的是，我们需要的专家应该懂得如何协作；他们知道如何在一起工作和沟通，这样我们就可以互相传授彼此的技能了。

• 自动化并不总是找出问题的最佳策略。我们需要经过分析和试验来找出至少做多少自动测试才够用，然后我们就可以腾出时间，使用探索性测试等方法涉足高风险领域。

• 测试人员需要学习 DevOps 实践、DevOps 文化和部署中的持续交付。

• 测试人员需要提升他们的沟通技巧。软件开发工作中编码技能占 20%，剩下的 80％都是沟通和协作。

敏捷是近年来的一大热门话题，但相关的争议也很多。有一种声音质疑敏捷能否面对测试的挑战。敏捷测试尝试从多个层面回答这个问题，包括组织、人员、流程、工具、沟通和协作等。Lisa Crispin 和 Janet Gregory 写过一些敏捷测试著作，还开设了一些在线课程。他们还为想要贡献和学习的人们建立了一个敏捷测试社区。他们的贡献帮助了敏捷知识、技术和文化在敏捷世界中普及传播。

Xiaoqian（Christina）Geng：你和 Janet Gregory 是敏捷测试的第一批布道人，还撰写了著名的书籍《敏捷测试：面向测试人员和团队的实用指南》，以及《更多敏捷测试：整个团队的学习之旅》。敏捷测试与成功的敏捷开发密不可分，并且应该成为后者的一部分。你认为成功实现敏捷转型的最大挑战是什么？

Lisa Crispin：我认为最大的挑战之一是人们并不是很了解敏捷，或者说一旦他们开始执行两周迭代和站会方法，就会前进得更快。我们必须学习很多新技能，其中一大重点是整个团队都要承担起质量保障和测试的责任。保障产品质量、构建测试基础架构、进行自动化和手动测试，还有建立信心以高频率交付小规模的改进，所有这些任务都需要人们的共同努力。为此，团队中的所有成员都需要参与测试活动。如果管理层不支持这种做法，不去鼓励人们关心测试并学习如何测试，那么所有开发人员就只会埋头编写功能却不去测试它们，这样的路线是行不通的。

如果开发人员的专业发展路线中包含测试技能，对他们的能力就很有建设意义。管理层需要了解这一点并将其纳入他们的技能组合中。因此我们认为有必要对管理人员培训测试相关的知识，因为他们并不是很了解测试。许多开发主管和业务主管都是这样，他们说应该提升质量，但是不明白这意味着什么，以及为什么要为此进行大量投资。最后，从长远来看质量提升是有回报的。如果你专注在速度上，你会走太多弯路，结果越来越慢。长期而言，你必须专注于质量才能提高速度。

Janet 和我写了一本新书。因为我们之前的著作都是大部头，所以我们写了一本名为《敏捷测试：简要介绍》的小册子，内容限制在一百页内。我们希望管理者和大家都可以读一读这本书，了解敏捷的概况。我们希望它可以吸引管理人员，让他们理解为什么他们需要支持自己的团队，让每个人都参与测试活动并提升产品的质量，从而实现敏捷转型。我们会自行出版这本册子，因为我们不想卖得太贵。我们会在 LeanPub 上架电子版，实体书则会登陆亚马逊。在这个所有人都希望实现持续交付或持续部署的时代，我们非常希望把这些信息传播出去。

几周前我们在 mabl.com 上发表了一篇博文，讲的是如果你能认真转向持续交付并采用 DevOps 文化，也就能顺利实现敏捷转型。当你需要努力做到每周一到两次，或者更频繁地交付时，你就会意识到我们确实需要自动化测试了。哦对了，我们也确实需要单元测试。我们确实需要尝试诸如测试驱动开发之类的实践，并把所有这些敏捷实践融通起来。如果不做这些事情，我们就无法成功转向持续交付。我们应该先定好这个目标，然后设法向这个目标靠近。就敏捷而言没有那么多条条框框，因为我们想要速度更快。

Geng：开发团队希望转向敏捷开发的原因之一是，人们认为它可以帮助提升新功能的交付速度。大多数情况下，如果在开发周期的一开始时没有做好测试工作，那么到了周期末尾时测试就会成为瓶颈。如果开发人员的优先事务列表里没有测试，那么他们也很难认同测试应该是开发工作的一部分。

Crispin：即使他们同意你的意见也不会照做，因为任务优先级不够高。所以我说管理层必须出来说话，

拿我上一个团队举例——开发总监明白我们需要各种自动化流程，也需要探索性测试。我们有许多自动化测试，但在投入生产时却遇到了问题，因为我们需要进行探索性测试。因此，他将其作为各个级别的开发人员的职业要求的一部分——他们需要特定的能力和探索性测试技能。然后他要求我们的测试人员在研讨会上教开发人员学习探索性测试。我们还定期与他们对接，让他们了解我们是如何测试的。我们还可以帮助他们编写测试：比如说你做这件事情会发生什么，或者应该对这件事情做负面测试之类；然后开发人员就会开始思考与测试相关的这些事情了。我们为他们提供了一些启发式检查清单，并使用了 Elizabeth Henderson 的测试备忘单。我们做的事情就是为他们的工具箱提供了一些新工具。他们很喜欢这样，因为这样一来他们就能尽早发现错误，也就看到了其中的好处。

Geng：有人说，一个 3 岁的男孩可以在视频游戏中找到错误，而一家制造公司的 CEO 也可以在金融应用程序中找到一些错误，诸如此类。这是否意味着每个人都可以进行测试？或者说，你认为开发人员可以代替测试人员完成后者的所有工作吗？

Crispin：显然，他们可以发展自己的能力并掌握许多测试技能。你知道 Alan Page 和 Brad Jensen 做了一个 AB 测试播客，过去几年里他们提出了所谓的“现代测试原理”。他们的愿景是让测试人员成为教练教授他们的团队，直到团队不再需要指导为止。这种做法可以在某些风险较低的业务领域中使用。但对于诸如金融服务之类的事务来说，其中金钱对于业务或生活是至关重要的，这种时候我认为你仍然需要专家来提供深层次的知识。你知道我已经做了 30 年的测试工作，难道我能将所有这些技能都传授给别人吗？我们需要测试专家。打个比方，我们可以学到一些有关用户体验设计的知识，但是对于大多数应用程序而言，我们的团队都需要设计专家。

Johanna Rothman 几周前写了一篇博文，她说在敏捷时代的早期人们会说："好嘛，我们都会成为通才；我们都会掌握这些技能。”然后她写道：“你知道后来发生了什么事吗？我们有了知道该如何协作的专家；他们学会了如何合作和良好地沟通，因此我们可以相互传递各自的技能。但我们还是会有专家，他们也没有被冷落在哪个角落。我们把所有专家都聚在了一起，这才是关键所在。” 我同意这一点。我们让专家们尽可能分享自己所有的技能。但你不可能在所有领域都是专家。我不认为大家都可以做到全知全能。

Geng：大型分布式平台可能具有数千种配置和高度可定制的部署。开发人员会花时间了解组件的依赖项，但是像客户一样理清所有头绪是需要开发人员花很多精力学习的事情。它需要深入的分析和对产品的全面理解。

Crispin：我认为领域知识是必不可少的。我真正深入到业务领域中后也获得了许多价值。开发人员必须专注于他们正在编写的一小段代码。他们必须集中精力。他们没有时间退一步来理解背后的业务整体。如果有我在，我可以帮助他们取得成功。

Geng：所以，我们不应该对开发人员抱有这种期望吗？

Crispin：对！

Geng：随着时间的流逝，测试自动化往往变得效率低下且昂贵。持续交付中最好的测试自动化策略是什么？

Crispin：Nicole Forsgren、Jez Humble 和 Gene Kim 合著的《Accelerate》一书是根据"DevOps 现状调查"的前四年结果编写的，这是一项科学调查。Forsgren 博士是一位专家，擅长使用此类数据并找出相关性，提出正确问题并找出联系背后的成因——成功做到持续交付的团队、客户满意的团队、团队成员热爱自己工作的团队往往是高绩效的团队。他们发现与开发团队高绩效相关的一个预测因素，是开发人员可以实现测试自动化；这样他们就可以自己在本地计算机上运行这些测试。他们可以在开发流程中处理持续集成中的测试失败。

而且他们与测试人员携手合作，所以两种角色你都需要。开发人员必须实现自动化，但他们也需要测试人员来帮助实施自动化并处理人工测试任务。这是我的经验之谈。当测试人员和开发人员携手实现自动化时，我们将获得最佳结果。我从过去二十年来的经验总结出了这一点。现在他们的科学数据支持了我的经验总结，这让我很高兴。现在你知道了这不只是某人的理论，而是事实。因此，我希望这一事实能帮助说服更多开发人员和他们的管理层，让他们意识到开发人员需要的不仅是自动化。许多开发人员不想做的不仅是服务级别或 API 测试，还有通过 UI 进行的 UI 测试。协作是必不可少的，因为测试人员擅长指定测试用例。我们需要将这些技能很好地结合在一起。

Geng：经过多年积累，自动化测试将成为一项巨大的测试资产，全都非常可靠且好用。但这条路有时走起来很困难。

Crispin：是的，这非常艰难，我们也为此感到挣扎。我们需要确保测试是正确的，需要确保我们有足够的覆盖范围。我们一定不能说：“那项测试总是通不过，干脆忽略掉整套测试吧。” 这非常危险。没那么重要的测试就不要去做。必要的测试就要让它足够可靠。我们应该对测试充满信心。我们一定要做好分析和试验，找出效果足够好的自动测试数量最少是多少，然后我们就可以腾出时间，通过探索性测试之类的方法涉足高风险领域了。有些测试最好是人工完成的，我们可以手动测试它们。我们应该搭配各种方法。对于持续交付来说，显然我们不可能那么快地手动测试完所有内容来支持持续交付，但是我们可以使用发布功能切换之类的东西，告诉大家：“好的，我们准备部署它了，先关掉它，或者只为我们开启它；我们会做好测试，稍后会为大家重新开放它的。” 我们有一大堆新技术可以用来做到这一点，这很令人鼓舞。但是我们仍然必须让专家在需要的地方提供帮助和协作，提供我们所需的所有技能。

Geng：我在 testingindevops.org 中看到了一个新词“DevTestOps”。能帮我们解释一下吗？

Crispin：一开始我们使用的是“DevTestOps”一词，过去也有人用过。我喜欢这个叫法，因为对我而言测试是开发运维的核心。你可以看看 Jez Humble 和 David Farley 写的《持续交付》之类的著作，那本书是 2009 年出版的。他们出版之前请我对草稿做了技术审查。当时我说：“我的团队做过这些实践，但我不是这些方面的专家。”

然后他们说：“不，我们就想让你来审。”所以我读了这本书。这本书实际写的都是关于测试的。这就是持续交付的核心。Jez Humble 非常支持我的说法。“DevTestOps”这个词，有些人喜欢它，有些人说这是在搞特殊，因为测试是开发的一部分——这一点我很清楚。测试人员需要学习 DevOps 实践、DevOps 文化和部署中的持续交付。这就是软件的发展方向。因此我们必须不断发展，我们的确需要这些技能。诸如风险分析之类的东西，我们作为测试员都很擅长。我们擅长识别模式，因此在使用 Splunk 这样的工具监视生产时，我们可以开始注意到其他人可能会忽略的模式，这就是我们的思维模式。我们可以使用可观察性指标来查看生产中发生的情况。人们如何使用我们的产品？我们需要将测试重点放在这里。我们可以使用许多工具来确定测试的位置，但是测试人员需要参与其中；而且我认为许多测试人员都会害怕听到 DevOps 这个词，他们觉得 DevOps 中没有测试的立足点。在持续交付中，我们是否有时间进行人工测试？人们不想去开发自动化测试，但却想要做测试。他们觉得如果只有自动化的测试，自己是不会参与进去的。我们需要向他们展示：“不，所有这些测试活动仍然是必要的。”我们只是在使用某些技术来换一种做法。这个网站的目的就是如此，是帮助人们了解这些内容。因此我们提供了一大堆文章、书籍、视频和播客的链接。然后我们会收到访客很棒的留言，我们希望能看到更多留言。我们欢迎大家提供帮助。我们会帮助大家提高认知水平、传授知识并让更多人为之雀跃。

Geng："现代测试原理"由 Alan Page 和 Brent Jensen 创建；他们称其为敏捷测试者的进化。借助现代测试的这七项原则，测试人员可以从质量的负责人转向使者的角色，带领团队提供可交付质量、提供价值并改善团队的质量文化。你怎么看待这件事？

Crispin：我认为这在许多业务领域都不会成为现实。团队中至少需要一名顾问来做一些专业测试。不同的开发人员有不同的视角。他们同一时间内只会专注于手头的工作。必须有人来把握全局。为此我们的团队需要测试人员，但可能不需要那么多。在我的上一个团队中，我们有 30 名开发人员和 3 名测试人员。我们不可能测试所有开发人员的所有输出，但是我们可以帮助开发人员学习在自己的故事级别内做探索性测试。因此，我们的测试人员会在功能级别上编写探索测试章程。当已经完成的故事足够多，可以开始测试功能时，我们可以让测试人员与产品负责人、设计师或开发人员结对，并在更高级别进行探索性测试。

我认为，如果团队的其他成员更进一步，正在提升他们的工作质量，则可以减少测试人员的数量。如果开发人员没有进行测试驱动的开发，或者至少没有自动化单元测试，那么一切都会徒劳无功。即使你在其他级别上实现了完全自动化，也无法替代一般单元测试中的自动化。开发人员必须有提高质量的意愿，然后他们才能做到这一点。我知道每个开发人员都希望提供高质量的产品，但是如果给他们压力，只要求他们把功能搞出来甚至更糟：“那么在下一个版本发布之后，我们将开始强化功能并开始自动测试。”这就像是在说我总是溺水所以没时间学习游泳一样。我们不应该成为质量的使者，而应该是推动者。我们的角色是帮助提醒大家，然后也帮助他们实现目标，让他们拥有能够实现这一质量水平的各种技能，但这需要整个团队发自内心的支持。他们必须自己有这样的意愿才行。

Geng：你认为团队中开发人员与测试人员/质量检查人员之间的正常比例应该是多少？

Crispin：从来没有哪个固定比例适用于所有团队。我认为团队需要问自己：“我们最大的问题是什么？”你遇到的最重要的问题是关于质量的——也许测试就是瓶颈。你需要搞清楚如何做测试。你可以找来更多的测试人员，也可以找来其他类型的测试人员。2003 年到 2012 年，我在一家金融服务公司工作，我们团队开发的是一种高风险软件。软件涉及的是人们的金钱； 我们的软件用来销售和管理雇主为其雇员提供的退休帐户。我们是一个很小的团队，但是业绩十分出色。编写代码并不难，但是要确保它能正常工作，并且每一个边缘状况都能处理就非常有挑战性了。我们谈论的是金钱；你必须计算到小数点后六位，一切都必须精确。因为如果你搞乱了什么东西，很难回退并撤销操作。我最后参与的一个团队开发的是项目跟踪工具；不管是谁的项目跟踪工具崩溃一段时间都不会出什么大问题。这并不是业务的关键角色，只是出问题会很烦人。它会让人不爽，但并不可怕。为 30 名开发人员配备两到三名测试人员是可以的，主要是因为这种文化非常注重质量。这种文化中还有结对编程；有测试驱动开发；还有人关心探索性测试。他们希望每个人都有旺盛的求知欲。在这种情况下，减少测试人员的数量没什么问题。我知道有些团队的开发人员很擅长测试，他们用不着测试人员。所以说还是具体案例具体分析。

Geng：应该怎样使用数据来衡量产品质量？

Crispin：衡量质量一直都是一项巨大的挑战。我一直在思考这个问题。Anne-Marie Charrett 在这方面做了一些非常有趣的工作。在不同的领域，不同的数据图所描绘出来的质量状况是不一样的。我认为，现在我们有了这么多出色的分析工具和所有这些数据，一种衡量的方法是问一个问题：人们是不是在使用某项功能？如果他们没在使用它，是因为他们不想要，还是因为它难以使用？还是说他们很难找到这个功能？我们可以使用学习型版本来判断。当我们开始研究新功能时，可以先做一个非常初级的最小可行产品（MVP）或学习型版本发布出去，观察用户使用它的情况，然后采访他们以获得反馈。我们发现如果能有一个反馈小部件（我说的是 Web 的应用）就很有用了——用户在这样一个小部件应用中轻点就能提交反馈。这些反馈对我们来说确实很有价值。我们跟踪的另一件事是“愤怒的点击”。就是说如果有人生气了，他们就会点啊、点啊、点……

我们团队的测试人员每周都会收集指标，并将其放在办公室的大型显示器上。这样我们就可以同时观察很多状况：收到多少张客户票，多少次愤怒点击，不同功能的使用率是多少，等等；并将它们组合为一系列指标。我们团队要做的一件事是经常给客户打电话，特别是打给新客户。比如说昨天他们联系了一家公司，后者对我们说他们需要在移动设备上使用我们的应用。我们尚不支持移动设备，所以召集了很多人来听客户的需求。如果产品人员来找我说“我需要这个新功能”，我会问：“我们怎么能知道它在生产中是不是能成功？”现在我们就来考虑一下该如何衡量它吧。很多时候他们甚至无法回答这个问题。

Geng：你认为诸如人工智能（AI）和机器学习之类的技术可以帮助我们的测试工作吗？

Crispin：测试平台 mabl 正在使用机器学习进行视觉检查。这非常好，因为经过一定数量的运行（例如 10 次）后，机器学习就可以识别屏幕的静态部分和一直在变化的部分。零售网站可能有很多种动态元素（例如弹窗和广告等），内容每天都有所不同。因此，机器学习知道我要忽略页面的哪些部分，因为它们一直都不一样。如果页面的某一部分看起来总是一样的，那么将来如果这些静态部分发生了变化，系统就可能会发出警告，因为你可能希望检查这里。它允许用户有一个基准，并可以知道内容是否有所变化。如果变化超出了基准，我们就要调查了。

这种技术还不是万无一失的。我认为它确实可以节省时间，针对页面加载时间也是一个道理。它给出一个平均页面加载时间，如果这个时间增加了一定百分比，就会出一个警告。但是，机器学习的水平主要取决于它训练时使用的数据，因此可能很危险。你可能会得出错误的结论，因为它训练时使用了错误的数据。因此我们在使用和广泛依赖它之前，必须在这方面了解更多信息。我认为我们必须更好地了解如何使用正确的数据来训练它；我们需要考虑所有可能性，因为它可能很危险。在测试这个领域，它的后果不像自动驾驶汽车那么糟糕，但是我们的产品主要只是一些灵感和代码的结合体。大家都希望 AI 解决我们所有的问题。我们当然正在朝着这个方向迈进，总有一天工具能够告诉你人们都在做些什么，告诉我们真实用户都在应用中做什么事情。显然会有一种能力来找出用户界面中最有价值的部分；我们的测试针对大多数组件的覆盖率如何？我们是否要测试这些页面并做断言？甚至这种工具也可能会为这些频繁使用的组件生成测试用例。

我认为这将对许多事情有所帮助，但需要特别意识到我们使用的不是魔术。这是我们能用到的工具。所以，我为它带来的可能性而感到兴奋。

Geng：研究人员已经在使用 AI 来做一些开发工作了。这个话题你能多谈一些吗？

Crispin：开发人员告诉我，与测试人员的工作相比，AI 更有可能承担开发人员的工作。举个例子，因为当我们使用机器学习时，我们使用的是数据；我们必须测试数据来验证它能否用来训练。我们必须测试机器学习算法。测试还是必要的，但是你可以为机器提供 2 万个编程示例，它就可以学习如何去编程。那是可行的。但是，你能让它获得人类的判断力吗？

Geng：最后一个问题，你对新测试人员有何建议？

Crispin：我认为重要的是，你要知道无论你的发现是什么——也许是错误？所有这些都可能是沟通问题：业务方没有很好地表达他们的需求；另一方面，开发团队误解了业务需求，因此看起来像是缺陷的东西其实只是因为沟通不畅造成的。因此，我会告诉测试人员提高你的沟通技巧。我曾多次听到人们说软件开发中编码技能占 20%，沟通和协作（所谓的软技能）占 80%。发展你的软技能，因为它们是最难学习的技能，例如沟通、聆听、观察技能，批判性思维技能等；并且有很多方法可以提升自己的软实力。你还需要注意自己的无意识偏见。测试人员非常脆弱，有时我们会测试我们期望看到的内容。我们必须能够注意到未知的事物，了解未知的事物。经常思考的能力对于测试人员是至关重要的。不用担心你的技术技能，这些很容易学习。

Geng：谢谢，这是对所有测试人员的普遍建议？

Crispin：我认为是的。我们学习了测试自动化或编程，或者其他很多很棒的东西。但是，我可以教任何人怎样去编码，但不一定可以教别人如何做到批判性思考。我可以给他们练习，帮助他们改进并努力。但具体该怎样做到这一点我也不能给出明确的答案。

Geng：Lisa，谢谢你花时间分享你的想法。与你交流真是一种荣幸。

受访者介绍

Lisa Crispin 与 Janet Gregory 合著了《敏捷测试：简要介绍》《更多敏捷测试：整个团队的学习之旅》（2014 年），《敏捷测试：测试人员和敏捷团队实用指南》（2009 年）， 还制作了"LiveLessons 敏捷测试基础知识视频课程"，以及"整个团队的敏捷测试方法"，并通过敏捷测试奖学金提供了为期 3 天的培训课程。最近，Lisa Crispin 和 Janet Gregory 出版了新书《敏捷测试精华》。Lisa 在 2012 年敏捷测试日被同行评选为最具影响力的敏捷测试专业人​​士。她是 mabl 的一名测试倡导者，致力于探索软件社区中领先的测试实践。请访问Lisa Crispin的网站和敏捷测试网站了解更多信息。

采访人介绍

Christina Geng 是位于旧金山的 Splunk HQ 的 QA/SDET 总监。她从事软件测试已经十多年了。Christina 对 SDLC 的持续改进和测试技术/流程发展、风险控制和客户至上等主题充满热情。

原文链接：

The Current and Future State of Testing: a Conversation with Lisa Crispin