软体测试 — 如何推动团队的测试文化?

我们分别谈了软体测试金字塔、测试驱动开发、实务上写测试时该注意的事项，这一期我们将把视角转换到资深工程师资深工程师，假如今天身为资深工程师，想要在团队中推动测试，该如何能更有效做好?

为什么团队不写测试?

在谈推动测试前，我们得先探讨为什么团队不写测试? 毕竟相信多数人都会同意软体测试有一定的好处，只是既然有这些好处，为什么不写呢?

以下我们探讨三个最常见的原因：

• 不知道该怎么写测试：有些团队成员不知道该怎么写测试，或是不知道在测试时可以搭配的相关方法，因为不知道所以就没有写。
• 没时间写测试：过去很多开发者会被怨没时间写测试，因为写测试花额外时间，会让功能来不及上线，而公司把优先顺序排在功能开发，导致最后只能牺牲没花时间在测试上。
• 认为测试是 QA 的工作：测试不只是写测试本身，而是软体设计与程式实作的一部分，唯有。目前业界越来越趋向，QA 的角色会是协助团队导入测试工具 (例如帮忙建立模拟测试伺服器 Mock Testing Server) 以及导入测试的最佳实践，但是测试本身仍会有开发者来写

以下我们会针对上面这几点，分别讨论身为资深工程师，可以如何帮助团队克服。假如你目前所在的团队，也有遇到这些问题，即使你的职称不是资深工程师，仍可以主动跳出来协助解决。

如何解决团队不会写测试的问题?

首先来谈团队不会写测试这点。多数开发者对于软体测试都有一定概念，但不一定会写测试，或者只会最基本的测试。然而，要有效在团队中推动测试，一个重要的点在于，要让团队成员对测试有所掌握，这包含对于测试的概念、方法、工具都有所掌握。毕竟假如团队成员连怎么写测试都不会，这样要求写测试会变得很困难。

过去在业界中最有名的导入测试案例之一，是当年 Google 透过在工程师经常会经过的地方 (例如厕所) 加上各种测试相关技巧的说明，让大家能够对于测试的掌握度更高。后来因为推动的很成功，甚至有 ToT (Testing on the Toilet) 一词专门来描述这件事。

具体来说，Google 早年时，公司整体对于软体测试的掌握并不高，软体测试并没有到很盛行。不过 Google 内有一群对软体测试很有热忱的工程师，他们尝试用各种方式协助改善这件事。而在厕所贴测试相关知识的想法，当初是在会议中被半开玩笑地提出，而其中有位工程师后来就直接去贴。

贴完后工程师们在上厕所时，不得不看到眼前的测试相关知识分享，包含依赖注入 (dependency injection)、各类测试时可以用的技巧、测试覆盖率的衡量、程式怎么写可以更容易测试等等。

在这群有热忱的工程师，直接这么做好，收到最多的抱怨，不是「怎么有人在厕所贴这种东西」，而是「这个内容怎么这么久还没更新」，许多工程师的抱怨是自己已经连续一周上厕所时，都是读同一个测试相关知识，他想要读新的知识点。从这个抱怨可以看到这个小尝试有多成功。

如果你对 Google 当时做的厕所测试内容感兴趣，详细的内容可以在《Software Engineering at Google》 一书中读到，或是很推荐当年参与推动的前 Google 工程师 Mike Bland 写的部落格文《Testing on the Toilet》。

回到 Google 当时这个尝试带给我们的启发点，在于要教会团队成员测试，可以把测试的概念，拆解成一个个小的知识点，用浅显的方式分享给团队成员，当测试知识变得够小、够好消化，团队自然能轻易学会测试。

这边最关键的，是身为团队的领导者，能否排除团队在尝试某个新东西时的阻碍? 当让做某件事变得越简单，就越容易导入，而团队领导者的任务之一，就是让团队成员做这件事情时能够很简单。

虽然在厕所推动测试听起来很简单，但实际做起来则不容易，因为这群推动 Google 测试文化的工程师，需要把许多不那么平易近人的概念，写得很简单，甚至简单到大家上厕所时看就能吸收。与此同时，他们也需要花很多时间去厘清、统一词汇 (以测试来说 fake、mock、stub 等词有点接近但又不同，需要有个清楚定义)。

进一步来说，当时这群工程师，有了这个半开玩笑的想法后，就直接去厕所贴，这体现一种行动趋向 (bias toward action) 的文化，同时意味着组织是允许有尝试的空间。回到团队领导者的角度看，去辨别出对策是主题有热情的人，给这些人空间去推动，这会是很关键的。

如何解决没时间写测试的问题?

接着来讨论，如何解决团队因为没时间写测试，所以不写测试的问题。首先，作为资深工程师，可以试着去跟工程经理、产品经理沟通测试的重要性，去争取把部分时间移来写测试。

但与此同时，更具体可以做的事情是，让写测试不用花很多时间。在给定测试能带来效益的状况下，让小测试只需用花很少的时间，就能更有效说服管理层，让团队能花少少的时间来写测试。

至于该如何做到呢? 身位资深工程师，可以把测试所需要的基础都先预备好，让写测试、跑测试变得很简单，甚至是比写程式、跑程式还简单，这样写测试就能变得很快。

具体来说可以做以下几件事：

• 建置好所需的测试工具： 举例来说，假如团队要导入 E2E 测试，资深工程师可以把 Playwright 搭配 Chromatic 的环境与流程都建置好，让团队成员只需用写测试就好，不用去担心各种环境问题。
• 把 CI 串好： 除了设置好工具，也可以把 CI 也串好，让测试自然地成为开发过程中的一环，让团队成员把程式码推到远端分之后，测试就会自动跑起来、测试覆盖率也会自动计算，甚至生成面板、产出报表，让团队能轻易地检视目前的状况。
• 导入 AI 工具到写测试当中： 由于 AI 工具近年来的蓬勃发展，目前业界逐渐出现导入 AI 工具到写测试当中。举例来说，目前比较多人用的 Cursor 即是可以导入的工具之一。这边推荐的方式，是把产品规格 (PRD) 的内容，或者某个功能的通过标准 (包含预期要有的 happy path 与必须特别处理的 edge case) 作为输入传给 AI 工具，然后请 AI 工具根据这些案例，来生成测试的程式码。

在我们过去实际导入的经验，当团队不用为环境问题烦恼，可以直接就开始写测试，这时搭配了 AI 工具，能让写测试变得非常非常轻松快速。

阅读更多

在了解最基本如何推动测试的要点后，接着我们会进一步谈为什么要把测试左移、为什么不推荐过度追求测试覆盖率。 这些点我们在 E+ 成长计划的主题文都有更详细谈到，推荐感兴趣的读者阅读。

本文为 E+ 成长计划的深度内容，截取段落开放免费阅读。欢迎加入 E+ 成长计划阅读完整版本 (点此了解 E+ 的详细介绍)。