没有 QA 人手的团队的现实
做完功能，自己点几下，然后就上线。换个浏览器长什么样、窄屏上什么会重叠、输入为空时会怎样，都没有时间确认。于是用户先发现，而其中会开口告诉你的只是一部分。
我们做什么
-
编写核心流程 E2E 测试
注册、登录、支付、发帖这些不能垮的流程，做成真实浏览器照着走一遍的自动化测试。
-
换组合反复运行
同一条流程，换着浏览器和屏幕尺寸反复跑。只在某个组合下才坏的问题，会在这时露出来。
-
跨浏览器确认
看 Chrome、Safari、Firefox 上同一个流程是不是走得一样，找出各浏览器之间不同的行为。
-
移动端画面检查
找窄屏上被截断、重叠或按不到的按钮，连同实际画面记录一起交给你。
-
边界情况探索
空值、超长输入、慢网络、重复点击、返回上一页，这些在真实使用中会出事的条件，我们特意放进去试。
缺陷报告
附上复现步骤、画面记录和严重程度。整理成读完不用再追问、可以直接开修的形式。没有可修的，我们就写没有。
这样开始
-
提供地址与核心流程
告诉我们服务地址和不能垮的流程。没有现成清单，我们一起整理。
-
编写测试
把你给的核心流程，写成真实浏览器照着走一遍的自动化测试。
-
整体运行与报告
给核心流程接上测试，逐个组合跑一遍，把跑出来的写成报告。
适合这样的地方
- 没有 QA 人手、即将上线的独立开发者
- 功能加得快、但回归缺陷反复出现的小团队
- 有支付或注册这类一垮就断收入的流程的服务
常见问题
- 需要把代码交给你们吗？
- 不需要。我们从公开的地址上，像用户一样用浏览器测试。不需要代码仓库的访问权限。
- 需要登录的页面也可以吗？
- 可以。给我们开一个测试专用账号，登录之后的流程也一起看。
- 你们也会帮忙修 Bug 吗？
- 这次检查包含的范围，到找出来并写成报告为止。如果也要修，会按单另行报价。
- 检查会看到什么程度？
- 以注册、登录、支付这类不能垮的核心流程为准，跨浏览器、移动端画面和边界情况都会看。