Tossincom QA平台：“任何人都能测试”的工具的开始

Source: Toss Tech

您好，我是 Toss Income QA 经理郑秀浩，前端助理卢奇贤。

在做 QA 工作时，我每天会收到好几次类似的问题。
“这个测试数据该怎么生成？”
“这个 API 在 Swagger 上怎么调用？”
“有没有办法直接查看这个状态？”

每次收到问题，我都会自然地打开 Swagger。找到需要的 API，说明 request body，并说：“这里要填这个值，这个要改成 true”。这在 QA 团队里已经是很熟悉的操作了。

但随着一次又一次的重复解释，我脑中浮现出一个想法。

“这些测试 API，为什么只有 QA 要这么麻烦地使用？”

Swagger에는 이미 모든 게 있었습니다

事实上，所需的测试 API 已经全部存在于 Swagger 文档中，并且整理得相当不错。
问题不在于是否有 API，而在于使用体验。对 QA 经理来说已经很熟悉，但对于开发者或策划人员来说，“想要快速确认当前状态一次”时，门槛仍然很高。因此在 QA 团队内部出现了这样的疑问。

“如果把分散在 Swagger 中的 Test API 汇集到一个地方会怎样？”
“再把它做成按钮会怎样？”

正是从这个问题开始，QA Platform 诞生了。

QA Platform 不会创建“新 API”

QA Platform 不会创建新的测试 API，而是直接使用 Swagger 中已经存在的测试 API。

我们所做的很简单。也就是说，我们并没有增加 API，而是更改了使用 API 的方式。

该工具是 QA 团队从构思、设计到开发全部 100 % 自主完成的内部平台。它从 QA 实际感到不便的地方出发，并以 QA 每天使用的标准进行设计。

Phase 1: 将 Swagger 测试 API 变成大家的工具

Phase 1 的目标非常明确。

“让任何人都能在没有说明的情况下执行 Swagger 中的 Test API。”

以前，为了生成测试数据，需要打开 Swagger，编写 JSON，并按顺序调用多个 API。一次小小的失误就可能需要从头再来。

在 QA Platform 中，这一过程被改成了这样。不需要打开 Swagger 文档，也不需要手动编写 JSON。只要看 UI 就能立刻知道“点击这个按钮会进行什么测试”。

Normal 模式和 Swagger 模式

并不是所有用户都需要同等程度的控制。因此 QA Platform 提供了两种输入方式。

得益于此，非 QA 成员可以轻松执行测试，而 QA 经理和工程师则可以根据需要进行深入控制。

小的 UX 带来的大差异

QA Platform 虽然是测试工具，但我们非常注重“每天使用的界面”。这些看似微不足道的功能，在重复操作时节省的时间相当可观。最重要的是，“要不要点一下这个”的心理门槛明显降低了。

Phase 2: 自动化也可通过按钮

如果 Phase 1 的目标是“让任何人都能执行 Test API”，那么 Phase 2 的目标是“让已经创建的自动化也能让任何人执行”。

目前虽然已经有自动化脚本，但执行主要由 QA 团队主导，环境配置和使用方法仍然存在障碍。Phase 2 将这些自动化资产整合进 QA Platform。

就像点击 Test API 一样，任何人都可以运行自动化。

Phase 3: 将测试管理统一

最终，QA 平台的目标是实现对整个测试过程的统一管理。我们希望在 3 月初之前构建一个符合我们组织测试方式的集成测试管理系统，而不是依赖外部工具。

结语 — 测试改变了，速度也随之改变

当测试变得困难时，产品自然会变慢。能够进行测试的人受到限制，运行一次测试需要经过多个环节，在面对“能马上确认这个吗？”的问题时，往往难以轻易回答“可以”。

从那一刻起，团队开始以猜测而非确信行事。验证被等待时间取代，速度逐渐下降。

我们在构建 QA 平台时最深刻感受到的变化，并不是因为添加了某个功能，而是测试变得容易本身。不需要打开 Swagger 文档，不必记住要使用哪个 API，也不必手动编写 JSON，更不需要按顺序调用多个 API。

只需点击一个按钮即可执行测试后，人们开始更频繁地进行测试。因为测试不再是“需要抽时间完成的特殊任务”，而是思路一出现就能立即进行的日常行为。

于是，产品的速度也随之改变。原本在确认后才行动的团队，变成了在确认的同时行动的团队，测试不再是束缚脚步的流程，而是快速生成下一个决策的工具。

测试变得容易的那一刻，产品变得更快。

对质量的看法

我们长期以来把质量视为“最后检查的事情”。也就是在功能完成、流程完备之后，检查是否有问题的角色。

在构建 QA Platform 的过程中，这种观念开始逐渐改变。测试 API 不再只由 QA 执行，而是任何人都可以运行，开发者可以在功能实现后立即自行验证，QA 也摆脱了重复的设置工作，能够专注于更重要的流程和风险。

质量不再是“最后阶段的检查清单”。它从一开始就自然地融入到流程中，成为加快决策速度的依据。

通过 QA Platform 我们想要打造的，并不是代替人执行测试的工具，而是 能够自然地进行质量设计的环境。不是谁来做，而是让每个人都能做的结构。

于是我们可以这么说：

质量不是检查，而是设计。

QA Platform 是从 QA 团队亲身感受到的不便出发，由 QA 团队自行策划、设计、开发的工具。但它的目标并非仅限于 QA。我们希望把测试从某个角色的专属职责，转变为全团队的日常行为。这样团队能够更快地实验，更有信心地前进。

在打造平台的过程中，我对自己有了一个明确的认识：帮助他人节省时间、消除不便是最让人愉快的事。

“这本来要花 10 分钟来设置，现在只要点一下按钮就行了。”
“现在不需要再去问 QA 了。”

这些反馈比新的按钮或自动化功能更让人印象深刻。

QA Platform 并不是从宏大的目标出发的项目。它源自每天重复出现的问题、每次都要解释的 API 调用、以及面对 “只想确认一次” 时的无奈。

我们没有把这种不便当作 “只能这样” 而是思考 “能不能消除它？” 于是产生了现在的 QA Platform。未来功能可能会增多、形态可能会变化，但 我们只会朝着帮助他人节省时间、减少在测试前犹豫的方向持续演进。

QA Platform 虽然由 QA 团队打造，却不是仅供 QA 使用的工具。如果能够让大家更轻松地检查、更快速地实验、更自信地做出下一步选择，那它已经充分发挥了作用。

今后，我仍将通过这个平台，持续致力于让他人的一天变得稍微轻松一点。