[Day26] QA 与系统

「老板，为因应多国语系，以及多平台的支援，我要增加 QA 团队的编制到对应的国家数与平台数。」这是我听前辈转述的历史，也是一个 QA 被团灭的故事。之前有提过，许多工程师习惯性的依赖 QA ，将程序品质的把关，全交由 QA 在发布前进行验证。严格说来，这属於 QC (Quality Control)。这样恶性循环的发展，当组织与产品随时间变得愈来愈复杂时，QC 的编制也必须愈来愈大。这可能吗？

让我们回归系统层面来思考，应该如何善用团队中珍贵的 QA 资源。

QA 与规画系统

回顾之前的开发系统流程图，在图中两个时间点，有 QA 的投入，对规画活动会带来最大的帮助。在 Refinement 中， 厉害的 QA 可以根据 Spec 分别对设计师与工程师提出建议。例如：

• 某个流程是否会造成使用者体验不佳
• 某个 UI 在过往类似的经验中，工程师容易忽略对多重点击 (Multi-touch) 的保护
• 各种前端、後端的错误处理

假设产品经理，设计师，工程师的合作，能把规画做到 80 分，而 QA 的投入，我认为可以补足到 95 分。为什麽不是 100 分呢？我认为在敏捷中，重要的是在交付价值，而不是追求完美，在规画阶段执着那最後那 5 分，实际边际效益可能不会太高。

在 Planning 之後， QA 可以再针对要交付的项目，做一次 Test Review ，目的是在与开发团队同步在该 Sprint 中的实作项目，要注意的相依性问题、QA 会加强测试的流程与元件，协助埋首开发的 RD 可以产出高品质的交付。

交棒 QA 的时机

一个最理想的状况是，团队与 QA 有高度的合作默契，在 Sprint 的结尾可以如期交付。但实际的经验中，在团队转型期，QA 最容易是承担高度张力的工作。我们来看一下 Sprint 行事历，如下图。 QA 通常是在 Sprint 的最後几天，才会拿到 RD 提供的测试版本。如果 RD 没顾好自己的产出品质，那麽 QA 的工作时间会进一步的被压缩。

这个系统问题，需要主管做一些判断。团队不会一天就改善到定位，不管是持续的教育会换血，老板在乎的商业价值永远是第一顺位。我采用过的变型方式，是让开发系统和 QA 系统独立开来，如下图：

这是为了舒缓系统张力，曾经使用过的一种方法。一旦团队的调整逐渐到位，我还是建议回归原本的节奏。

团队系统的 QA

之前的文章有提过，我把团队系统当作一个产品，如果在设计系统的同时，有 QA 加入，对各个讯息结点、产出、Retro 进行品质审查，我认为可以会有更好的效果。目前的团队中，我就尝试与 QA 进行跳脱产品生产的维度，来看组织面的品质。其实，我认识不少 QA 出生的高阶主管，对风险控管与量化的思维，对我有更多的指导。

不厌其烦的再提醒，不要把 QA 当 QC ，如果认同规画系统的价值，就更该让 QA 在其中发挥专业，品质的提升不应只专注在交付，从规画时就该注意喔！