初创公司 CTO 或 VPE 面临的必然问题
作者注：这篇文章于 2025 年 1 月发布，但在同年 3 月，我意识到遗漏了合成监控的部分，因此在此进行了补充。
你是如何走到这一步的
你努力工作，带领公司的技术团队和产品度过了 MVP 阶段。你的客户群正在增长，你开始看到一些 bug 出现，其中一些导致了严重的客户投诉。不断增加的 bug 数量以及由于关键 bug 而不得不回滚发布，让产品和业务感到沮丧，也让开发团队感到疲惫。你希望能够在发布时避免回滚的麻烦，或者在修复 P0 问题时不至于手忙脚乱，同时还要处理愤怒的客户。你记得在之前的公司有一个 QA 团队，工程团队依赖他们来认证发布并在发布前发现 bug。虽然它并不完美，但也许这可以解决你的问题——只需出去聘请一名或一批 QA。这可能会为你的团队争取一些时间，以获得足够的业务 momentum，弄清楚产品的下一个增长阶段，甚至可能为下一轮融资做好准备。
为什么我不会急于聘请 QA 或组建 QA 团队
聘请 QA 就像聘请开发人员或项目经理一样。你将不得不招聘、雇佣、入职，然后管理他们。不像你，不是所有的测试专业人士都有主人（而不是员工）的态度，即这仅仅是一份工作，他们没有动力或激励去关心业务或你的客户。当他们第一天上班时，不要惊讶于他们会告诉你，他们下个月要去亚洲或非洲（因为他们几个月前就预订了行程），或者他们要忙于家庭装修，或者要结婚并需要休假。作为一个好的人员管理者，你祝贺他们，并希望他们回来后能有动力并渴望完成工作。如果你幸运的话是的，但很可能你会遇到另一个理由让他们离开，而所有给出的理由都是合理的。这并不真正取决于这些资源是远程的还是办公室的。每个国家都有自己的劳动法，你必须遵守这些法律。
在我的经验中，至少有 50% 的测试专业人士在技术上非常薄弱。在 [1] 中，我阐述了我对测试工程师的期望。作为一名质量工程领导者，我面试了很多所谓的“测试工程师”。在我的筛选面试中，涵盖了 REST 的基础知识和算法问题解决，大约 80% 的候选人没有达到标准。如果这些人被雇佣，就会导致 QA 令开发团队沮丧的情况。我在 [1] 中提到了一个这样的案例。从我的经验来看，除非他们有一些先前的经验，否则大多数工程领导者不知道如何区分小麦和谷壳。我不得不接管 QA 团队，并因之前的招聘错误而管理人员。
有哪些替代聘请 QA 的方法？
那么，作为一名工程领导者，你应该做什么？你仍然有发布质量的问题需要解决。以下是一些选择：
增加单元测试覆盖率
我曾经与一个移动应用团队合作，他们的应用既有 iOS 版本也有 Android 版本。iOS 团队的单元测试覆盖率约为 90%，而 Android 团队约为 60%。iOS 团队遇到的唯一问题是与硬件兼容性有关的问题，需要我的团队利用我们测试实验室的设置来发现。然而，Android 团队却有非常基本的功能问题，这些问题可能会随着构建的推进而退化。这向我证明了单元测试在确保一定程度质量方面的重要性。
对于一个只有软件开发人员的团队来说，这也是一个唾手可得的成果。留出一些时间来提高你的单元测试覆盖率。让你的代码仓库连接到像 SonarQube 这样的工具，并从构建到构建进行跟踪。
你现在有一个优势，大多数编码助手（例如 Copilot）将协助单元测试的生成。这允许你的团队加快达到某种覆盖水平的速度。
增加 E2E 测试覆盖率
你可以做的另一件事是与你的开发团队一起建立你的 E2E 测试自动化。建议达到一定程度的单元测试覆盖率，以便团队至少在代码中设置了“婴儿防护栏”，这有助于整体代码质量和代码审查（见 [2]）。
然而，我理解在发布前系列 A 和系列 A 公司中，快速发布代码以验证产品假设是成功的关键。在系列 B 中，你也需要开发团队解决客户问题并使平台成熟以实现规模化。此外，代码库可能用“胶带和口香糖”拼凑在一起，单元测试可能在所需的时间范围内不会产生足够的影响。代码将在某个时候需要进行重大重构以使其可测试，但那时还不是时候。因此，可能有意义的是利用有限的资源来建立 E2E 测试覆盖率，即使没有将单元测试覆盖率提高到令人满意的水平。
一种方法是聘请许多外包公司之一来为你建立 E2E 测试框架。我怀疑你不会很难找到一个——只要在 LinkedIn 上将自己列为 VPE 或 CTO，他们就会主动联系你。问题是如何评估他们是否值得这个成本。
一些可以帮助你构建 E2E 测试套件的工具包括：
- Autify Genesis —— 接受产品需求并生成 Playwright 代码（以及测试用例）
- ContextQA —— 接受你网站的点击流并生成“知识图谱”，并为你选择的用户流生成测试代码
- Mobot —— 你提供步骤，他们为移动设备创建测试自动化
群众外包测试覆盖率
如果没有时间来提高单元测试覆盖率或设置 E2E 测试，一个短期到中期的解决方案是与几家群众外包软件测试公司之一合作。一些例子包括：
- Rainforest QA
- Applause
- Testlio
这些公司涵盖 Web、Mobile、一定程度的性能测试、无障碍性和本地化测试。对于一定的费用（或包含在 SOW 的成本中），你可以得到一个项目经理与你合作开发测试计划并管理这些测试的执行。他们会与你的 bug 跟踪系统集成，并发送已识别的 bug 及其重现步骤。
这些公司的最大优点是他们几乎全年 365 天都在运营。如果团队中的任何人休假，由他们自己负责找人替代，因此不会出现服务中断。此外，由于他们是全球性的，他们的测试资源可能在世界的另一端，因此你可以采用“跟随太阳”的方法来进行你的构建-测试周期。
使用合成监控
如果你还没有投资合成监控，你至少应该看看它。合成监控是一种性能监控，它使用自动化脚本或机器人来模拟用户与网站、应用程序或 API 的交互。然而，一种合成监控，即脚本事务，创建并执行预定义的用户交互，如登录、搜索、将项目添加到购物车或完成结账过程。这些可以用于在生产环境中的部署后对你的网站进行 sanity 测试，也可以作为预生产测试的一部分。
提供这种服务的公司包括：
- Catchpoint
- Datadog
- New Relic
- Checkly
在这些公司中，我想提一下 Checkly，因为他们是 Playwright 本地的。这很好，因为你不需要做太多工作就可以将用于预生产测试的任何现有 Playwright 代码转换为用作合成监控的代码。现在，如果你的预生产环境可以通过互联网访问，你也可以运行你的 Checkly 测试来检查预生产环境，然后再发布。
我是根据经验在说话
我的职业生涯从一个由 6 名工程师组成的开发团队开始（没有 QA），我们做了所有事情，包括确保质量。后来，当我加入 Yahoo 的移动团队时（那时移动主要是 SMS 和 WAP），只有我、工程师和产品经理。我们两个人都测试了我们的服务。我知道在某个规模上，没有 QA 或 QA 团队也是可以运作的。
我职业生涯的其余时间都在构建和运行 QA 团队，并协调内部、外包和群众外包的测试资源。
那么，什么时候是聘请 QA 的合适时机呢？
总有一天，为了扩展，你可能需要聘请一个内部 QA 团队。如何判断你是否已经到了这个阶段？这是后续文章的主题。如果你愿意，可以随时联系我，了解对你的情况的看法。
