# 没有QA就没有Bug


关于测试左移 shift left 的讨论已经持续了很长一段时间了，前几天刚好看到有外国友人亲身参与了这个过程，结果有点出人意料，所以翻译出来分享了一下。

在 2017 年，成为一名 QA 是一个有趣的时间。但不是搞笑哈哈，是有点点诡异了。每个人都想着测试左移（在合理范围内），但不是为了提高他们的质量，他们会以减少传统的质量保障人员的瓶颈的心态来做，那就是在迭代结束时，测试所有的东西。

我记得几年前，我是一个由 5 个开发人员组成的团队中唯一的 QA，我们没有大量的自动化测试，但左移的思维方式得到了应用，至少是部分应用。我在开发人员做需求时，尽早地帮助他们，这在迭代结束后会得到回报，测试阶段的时间是最少的。充其量，我们会在测试阶段发现一两个问题，并迅速修复它们（或假设该问题到下一个版本）。

公司内部的一个新项目已经开始了，他们想在一开始就应用左移的思维方式，但他们不需要 QA。所有的工作都可以通过自动化测试完成，开发人员将完全承担和拥有这些测试。作为一个 QA 人员，我很好奇，我想看看他们是怎么做的，他们是怎么涵盖这个用例的，或者其他用例的，我想学习并帮助他们。但是我被推到了一边，因为自动化才是王道，不需要 "手动 QA"。

当他们在几个月后找到我的时候，我遇到了 "告诉你 "的时刻，他们在生产中出现了大量的问题。那是一个混乱的局面。这时他们意识到，即使他们写了大量的测试，他们也没有考虑到他们的测试策略。解决方案是在团队中加入一个 "手动 QA"，来处理应用程序的问题，防止生产中出现更多的错误。

快到今天，我意识到他们已经非常接近了。他们拥有自动化测试策略。团队中的任何新开发人员都经历了严格的代码覆盖率、配对编程和细致的提交代码审核过程。他们唯一缺少的是一个好的测试策略，按照测试金字塔的描述进行工作（我知道你们中的一些人鄙视这个，但有时，它真的可以帮助团队分类并专注于正确的事情！），以及在用户体验上多想一点。

### 那么，你的 QA 团队成员可以在左移的转型或项目中扮演什么角色呢？

- 在开始 "左移 "时，文档被证明是有用的。通过确保针对现有功能和新功能中最关键的点，它可以更容易地从传统的方法过渡。通常把重点放在用户的关键功能和你的应用程序中常见的脆弱点上。
- 参加研发的启动会议。帮助提前考虑潜在的问题，用例子来引导这些会议是最好的做法。就我个人而言，我更喜欢在开发人员开始一个需求时以非正式的方式召开这些会议，但你也可以把这些会议变成一个定期会议，类似于你的 scrum 计划和复盘会议。这种做法也被称为 3 amigos（读起来不错）。
- 学会阅读代码，看看 PR 评论，学习自动化，你的 QA 团队成员越是多才多艺，开发人员就越有信心作为一个团队来交付他们的功能，而不是依赖一个 QA 警察。

如果你的团队没有一个已经在职的 QA，你的团队已经可以开始应用同样的准则。停下来，呼吸，花 15 分钟思考可能的测试用例。不要在功能上走得太深，但思考所有可能的用户行为有很大的帮助。把它们写下来 👏。这将帮助你防止很多 "我没有想到的 "情况。

虽然这不是一个完美的指南，但这是很好的第一步，我称之为 "在 3 天周末前的星期五下午 4 点部署的信心"。但这是另一个故事了。