关于敏捷项目里质量保障的文章，大家应该看了不少了。

质量已经不再是简单地通过 “发现 Bug -> 修复 -> 验证” 这个流程来解决的问题，而是通过一系列的质量活动来保证的目标，正所谓预防为主！

我们的目标也不应该再是找多少数量级的 Bug 了，而应该是在通往高质量的这条路上，我们能够设置哪些关卡来预防质量出现问题（设置关卡的过程其实就是建立质量流程的过程），与此同时，尽量保证各关卡的工作是有价值的，避免各关卡的工作重复度太高。

不要单纯地认为质量就是指交付产品的质量，它同时还包含整个项目过程中的质量流程是否最优，质量工作是否高效。我个人给到的公式是：

项目质量 = 流程 + 效率 + 产出物。

那么，这个过程中的质量切入点都在哪儿呢？
下边是我梳理的部分内容。

Test strategy

测试策略不是制定出一个就一用到底的，而是需要阶段性地进行调整。

质量切入点：
- QA主导整个Team共同讨论并制定项目的Test strategy；
- 回顾上一个阶段我们所遵循的测试策略是什么；
- 依据测试金字塔，
  $ 团队根据上一阶段的实践，总结每一层出现的问题，或者可以改进的部分；
  $ 针对每一个问题，每个人依据自己过往的项目经验和总结，发表自己的观点，讨论出有针对性的Action；
  $ 过程中一定要跟所有人确认，是否理解其他人的输出（尤其是新来的小伙伴儿），是否同意其他人的观点；
  $ 最后将所有内容整理归档，并公布于团队。

这里的重点是，Test strategy 一定是团队达成一致的产物，而不是某个人制定出来的。

Backlog Grooming / Backlog Refinement

对 Backlog 里的卡片进行一次洗牌。

质量切入点：
- 识别业务关联性，合理安排测试优先级，提高测试效率；
- 识别测试类型：手工测试、API测试，UI自动化测试，性能测试……；
- 识别信息缺失，比如：文案、UI设计等是否Ready，避免影响交付效率；
- 协助team识别当前高优先级的Bug卡，并删除无效Bug（此时无效可能由于修复其他问题或者开发其他功能的过程中已经将问题修复）。

IPM / Sprint Planning / Iteration Kick off

明确下一个迭代的重点是什么。

质量切入点：
- 估点的时候注意了：一定提醒团队将测试（写Unit Test、Integration Test、自测等，以及In QA阶段的Double check）的时间包含在内，同时根据卡片功能特性，评估其对已有功能产生影响的风险，从而决定是否需要增加Buffer去处理这部分可能产生的问题。
- 如果在当前迭代有时间较长的休假计划（超过3天），提前提出来。
  $ 准备好自己休假这段时间的Handover plan；
  $ 找好自己的Replacement，确保项目进度不受影响；
  $ 尽可能在休假前一天将自己手头上的工作闭环，并给团队发送一条各项工作的进度更新。

Card Grooming

Dev 捡卡到开卡前对卡片进行分析、任务拆分、细节补充。

质量切入点：
- 有没有Block；
- 需不需要拆卡；
- 拆分Task；
- 补充AC细节；
- 补充Test point。

Card Kick Off

开卡，Dev 邀请 BA、QA 一起 Go through 卡片细节，确保大家的理解是一致的。

质量切入点：
- 识别业务信息是否足够清晰；
- 相应的UI设计是否已经附在卡片上，以保证实现是有据可依的；
- 识别是否需要QA介入进行Double check
  $ 业务卡
  $ Bug卡
  $ 技术卡
  $ CI卡

In Dev

Dev 对卡片进行开发。

质量切入点：
- Unit test；
- Integration test；
- 自测。

项目条件允许的情况下，这个环节最好 Pair 进行，可以互相讨论、互相补充、互相 “监督”、互相 Backup。

PR Review

另外 1、2 名 Dev 对提交的代码进行 Review。

质量切入点：
- 命名是否符合命名规则；
- Unit test、Integration test是否全面、是否冗余；
- 代码的可读性、可复用性、可维护性等是否够好。

Desk Check

Dev 与 BA、QA、UX 的 mini showcase（有些项目中，客户方的 PM 或者 PO 也会参与到 DC 当中，判断是否符合心理预期，尽早给出 Feedback，尽早做出调整）。

质量切入点：
- 某些接口的异常校验有没有覆盖到；
- 某些特殊的浏览器有没有自测过；
- 有没有考虑移动设备上的展示；
- 跟Dev问问实现细节（这部分信息会帮助你覆盖到更全面的场景，并确定Regression的范围）
  $ 逻辑是如何更改的；
  $ 所更改的方法被哪些功能模块调用。

In QA

对卡片内容进行 Double check，但更多的时间应该花在 Regression test 和 Exploratory test 上。

质量切入点：
- Desk Check过程中还有没有没考虑到的场景；
- 哪些功能会因为当前卡的代码改动而受到影响；
- 邀请Dev一起Pair进行QA（不要认为只有coding才需要pair，测试同样可以pair进行，目的是相关补充、相互学习）。
  $ QA可以通过Dev了解更多代码更改的影响面；
  $ Dev也能同时了解测试如何开展，测试场景如何设计等测试技能。

其实我更倾向于称 In QA 阶段的工作叫 Double check，而不是 Testing。

我们已经可以通过 Unit test、Integration test、API test、Dev 自测以及 DC 过程中的 mini showcase 来保证每张卡片的质量，这些都属于 Testing。而我们在 In QA 阶段需要做的更多的是去挖掘在之前阶段没有 cover 到的部分（Regression test + Exploring test）。

Done

对卡片做闭环。

- 质量切入点：
- 是否符合Done的标准。

别看只是简单的一个做闭环的动作，依旧存在质量风险，尤其对于新人来说。

经常有同学跟我说很纠结卡片能不能或者应不应该拖到 Done：

• 卡片在测试环境上测好了，但是线上环境还没搭好，所以没办法在线上环境验证，能拖到 Done 吗？
• 卡片的测试工作已经完成，但是流水线坏了，能拖到 Done 吗？
• 有一张之前的卡，已经在 Done 里了，接手的时候，发现里边列的很多场景都没有被执行过，能把这卡再拖回来吗？

单纯地让我回答 “能” 或者 “不能”，sorry，回答不了，我只会反问你，团队定义的 Done 的标准是什么？如果你也不知道，记到小本本上吧，然后回去 Drive 团队把这件事情落实一下。

Daily stand up

团队每天对自己的工作内容、进度进行简短更新。

质量切入点：
- 卡片测试环节需不需要support
  $ 技术上的support（一般因为某些特殊场景需要造数据、或者需要通过代码的形式造符合要求的测试场景等）；
  $ 人员上的support（往往因为积在Ready for QA的卡片数量过多）；
  $ Block进度的第三方系统问题，需不需要客户协助。

不要小看这 15 分钟时间，可能其中的某一分钟就能解决你的 Blocker 或者效率问题。

Retro

对迭代（Sprint / Iteration）中发现的问题进行回顾，总结并找到解决方案，让团队更好地发展。

质量切入点：
- 可以在Retro中提出任何跟质量相关的点，比如：
  $ Well：
    §  团队均能够主动戴起QA Hat保证交付质量（基于你能否将质量意识、技能传递给团队）；
    §  团队里谁在质量上有什么贡献（基于你是一个好的Observer）；
    §  团队这一阶段的Bug量呈下降趋势（基于团队已经有一套相对完整的质量保证体系）。
  $ Less well：
    §  测试进度慢；
    §  线上Bug多；
    §  没有办法focus在测试上；
    §  质量流程中哪个环节出现了什么问题。

Could happen at any time

任何时候都可以发生的事情。

质量切入点：
- 文档 - 这是一件利人利己的事情（利人：比如谁因为需要通过你们组的业务流程创建一条数据找到你，链接发给他即可；利己：同样的示例，利人的同时其实已经利己了，给自己省去了亲自上阵点一遍业务流程的时间）。
  $ 业务流程梳理；
  $ 解决方案梳理；
  $ 测试工具使用；
  $ 各种总结。
- Bug bash
  $ 大家一起来找茬（Bug）；
  $ 挖掘可优化的用户体验；
  $ 顺便探索其他团队的Bug，并告知。
- Session / Workshop
  $ 通过分享自己对业务、技术等的理解，获取其他人的反馈，从而判断自己的理解是否正确，还有哪些没有学到的部分，帮助自己制定下一步计划；
  $ 为团队整体能力的提升出一份力。

其实全篇提到的 “质量切入点”，是在整个项目过程中，为了达到最终 “高质量、高效率” 的效果，可以做的任何事情（包含但不限于上述所列举出来的流程和内容）。这些事情可以是提问，可以是实操，可以是沟通，可以是总结。

所以，质量切入点在整个项目当中无处不在，想要找到它们，质量流程建立起来了吗？