1.当团队的单元测试覆盖率低的时候，经常会出现新增加的功能代码破坏掉已有的功能。同时也会造成比较多的漏测情况。因此我会关注单元测试覆盖率能否达到对应的覆盖程度，并促使团队把单元测试覆盖率工具加到 CI 上。

2.当开发测试微服务时，为了隔离微服务并让测试运行的更快，团队使用了 mock 方法，但这种方法会有一些弊端，例如测试多个微服务之间的调用时，边界处如果有 Bug 往往会出现漏测，因此我补充写了一些 E2E 脚本跨多个服务之间，去测试完整的流程，避免漏测的现象。

3.建议团队根据测试金字塔，补充更多的 e2e 自动化测试，至少需要覆盖业务流程中的 happy path 和主要的异常流程。有了这些单元测试和 e2e 测试，QA 的回归测试就可以减少很少，QA 可以投入更多的时间在新模块的测试中。

4.有一段时间，在我们的 Jira 墙没有 UI 验证的 coloumn，我建议加上这一列，让 UI 设计人员从专业的什么角度，去验证交付的产品从整体上是符合统一审美的。

5.有一段时间，有的故事卡会测出 10 多个 bug，回到开发进行修复后，还会发现几个新的 bug。我认为是由于卡的范围过大造成的，这类大卡会造成质量反馈周期慢，因此需要缩小卡的范围，把大卡拆分成更细的小卡，可以加快质量反馈周期。

6.为了提高软件产品的可测性，建议开发人员在每个 web element 上加上 ID。因为如果 web 界面上的元素没有 id，那自动化测试时候需要用 xpath 等根据元素的层级关系去定位，比较麻烦也容易出现错误。如果有了 id，那么自动化测试写起来就容易多了。

7.建议团队给产品加一个功能，当 url 上输入一个特殊地址，打开可以看到部署的这个产品的版本号，以及一些其他可以对外公开的代码相关信息，这样方便每个人都快速了解到当前产品的部署细节信息。当产品出现 bug 后，可以更方便的定位出错原因。

8.组织 Bug Bash，让项目所有人从不同的视角测试一起测试软件，往往会发现更具特殊性的 bug。