认识负责质量的团队（01 Meet the Teams Responsible for Quality）
本单元聚焦软件开发生命周期（SDLC）中负责质量的三个核心团队——开发（Development）、运维（Operations）和业务（Business），并探讨"左移"（Shifting Left）如何把质量职责更早地分布到生命周期的各个阶段。
学习目标 — 完成本单元后，你将能够：
- 识别在 SDLC 中负责质量的团队
- 解释"左移"（Shifting Left）的概念
- 描述质量职责在 SDLC 各阶段的分布
谁对质量负责？（Who Is Responsible for Quality?）
对一些人来说，质量等同于测试，但事实远不止如此。测试固然是质量的关键组成部分，但质量还涉及解决问题、设定优先级、提出与接受反馈，以及最重要的是——为最终用户交付价值。所有这些活动，只有通过团队协作的方式才能最好地完成。
我们所说的"团队"，指的是在项目任何阶段参与的每一个人。在向用户交付软件的过程中，涉及许多干系人（stakeholder），他们每个人都在确保软件质量方面扮演着重要角色。因此，质量是一项共同的责任（shared responsibility）。
需要说明的是，与质量相关的具体职位名称会因行业、公司规模、团队动态、个人专长等因素而有很大差异。为简化起见，我们使用通用的干系人分组——开发、运维和业务，具体细节则留给你自己的独特情境。
传统观念认为 QA（质量保证）独自拥有质量，在流程末尾查找缺陷；现代观念则认为每个人都拥有质量，在上游就预防缺陷。当质量成为每个人的工作时：缺陷被更早地捕获（修复成本更低）、团队协作而非相互指责、质量是"内置"（built in）而非在末尾"检查进来"（inspected in）。
开发团队（Development）
开发（简称 dev）的传统职责领域，是按照所有干系人设定的需求来编写功能代码。相关的角色包括 Salesforce 开发者（Developer）、Salesforce 架构师（Architect）和 Salesforce 设计师（Designer）。
开发团队是质量的第一道防线，其关键质量职责包括：
- 编写干净、可维护、可测试的代码
- 单元测试（Unit Testing）——验证各个组件能正常工作
- 代码评审（Code Review）——合并前的同行审查
- 静态代码分析（Static Code Analysis）——自动化质量关卡
- 重构（Refactoring）——持续改善代码健康度
此外，开发团队还通过 测试驱动开发（TDD）、结对编程（Pair Programming）以及持续集成（Continuous Integration）等实践，把质量思维融入写代码这一动作本身，而不是把它当作一个独立的阶段。
目标很明确：在代码层面就捕获缺陷，避免它们演变成生产环境的 bug。最便宜的修复，就是那个从未到达用户的修复。
运维团队（Operations）
随着软件变更发布得越来越频繁，质量也迫切需要跟上节奏。测试和安全由此覆盖到运维（ops）领域，在编写代码之前就为质量活动提供输入，并在产品与功能构建完成之后对其进行监控。
相关角色包括 测试工程师、经理或分析师、质量保证工程师、专家或分析师，以及网络安全（Cybersecurity）相关岗位。
运维团队确保质量体现在部署和运行时，其关键质量职责包括：
- 部署自动化——一致、可重复的发布
- 环境管理——开发、测试、预发与生产环境保持一致
- 监控与告警——在用户报告之前就发现问题
- 事件响应——快速恢复、无指责的事后复盘（postmortem）
- 性能与可扩展性测试
运维侧的 DevOps 实践还包括 基础设施即代码（IaC）、持续交付（Continuous Delivery）、可观测性（Observability）以及混沌工程（Chaos Engineering）。其目标是：在开发环境能正常工作的代码，在生产环境也必须能正常工作——运维就是弥合这道鸿沟的那一环。
业务团队（Business）
业务代表连接了众多领域，包括工程、产品、营销、销售，当然还有客户。虽然他们可能不直接写代码或修复 bug，但他们对项目的时间、资源与规划管理至关重要。
相关角色包括 Salesforce 管理员（Administrator）、Salesforce 顾问（Consultant）、业务分析师（Business Analyst）以及 Salesforce 设计师（Designer）。
业务团队定义了质量到底意味着什么，其关键质量职责包括：
- 清晰、无歧义的需求
- 验收标准（Acceptance Criteria）——"完成"到底长什么样？
- 用户故事细化（User Story Refinement）——把工作拆成可测试的块
- 优先级排序——先修最要紧的问题
- 用户验收测试（UAT）——它是否解决了真实的问题？
业务侧的质量实践包括 行为驱动开发（BDD）、三个朋友（Three Amigos）（开发、QA、业务共同协作）以及完成的定义（Definition of Done）。目标在于：构建正确的东西，而不只是把事情做正确——一个编码完美却用错了地方的功能，仍然是质量的失败。
将来自不同领域的视角引入 SDLC，能提升整体质量。无论团队结构如何，请注意质量被列为每一个群体的职责——这不仅包括有助于质量的活动，也包括塑造质量文化的行动。
左移（Shifting Left）
SDLC 由五个阶段组成：需求（Requirements）、设计（Design）、开发（Development）、测试（Testing）和部署（Deployment）。你或许会想：测试是流程中独立的一个阶段，所以所有测试当然都发生在那里，对吗？答案既是肯定的，也是否定的。
测试固然是它自己独立且必不可少的阶段，但同样重要的是从始至终（乃至之后）都要测试。这种"在流程中更早进行测试"的理念，被称为左移（Shifting Left）。
把测试更早地引入 SDLC，能帮助团队跟上更快的开发节奏。太晚才开始测试会浪费时间、使进行中的工作陷入瓶颈，还会让小问题演变成大事故。
左移意味着把质量活动移动到生命周期的最早节点：
- 测试——开发阶段的单元测试，而非 QA 在末尾的补测
- 安全——设计阶段的威胁建模，而非开发后的渗透测试
- 性能——CI 中的负载测试，而非生产出问题后的补救
- 无障碍（Accessibility）——设计评审，而非事后的整改工单
为什么要左移？因为缺陷的修复成本随阶段推进呈指数级增长——一个需求阶段的 bug 修复成本是 1 倍，而一个生产环境的 bug 修复成本可能是 100 倍。左移，就是把成本压下来。团队越早开始测试，流程就越顺畅。
SDLC 各阶段的质量职责（Responsibilities Across the SDLC）
质量不是某个阶段，而是贯穿 SDLC 所有阶段的一条连续主线：
- 规划（Plan）——业务定义需求与验收标准
- 构建（Build）——开发编写干净的代码与单元测试
- 验证（Verify）——自动化 CI 检查 + 代码评审 + QA 测试
- 部署（Deploy）——运维确保可靠、可重复的发布
- 监控（Monitor）——运维观察运行时行为与用户反馈
- 学习（Learn）——所有团队复盘事件、改进流程
每个阶段都设有质量关卡：
- 规划：需求是否清晰、可测试？
- 构建：代码是否通过静态分析与单元测试？
- 验证：集成测试是否通过？UAT 是否获批？
- 部署：部署是否成功？冒烟测试（smoke test）是否通过？
- 监控：错误率与性能是否在 SLO 之内？
- 学习：下一轮我们能改进什么？
质量是一个循环，而非一次性的检查点——每一次迭代都把学到的经验反馈回下一轮规划中。
循环仍在继续（The Cycle Continues）
部署是 SDLC 的最后一个阶段，但未必是旅程的终点。即使在功能部署之后，循环仍在继续。
- 在回顾会议（Retrospective）中，干系人聚在一起复盘整个过程中的工作，识别挑战与未来改进的机会。对团队而言，这些回顾会议是持续改进的关键组成部分。
- 测试也是一项持续进行的活动——它贯穿整个开发周期，并且在周期结束后仍需继续。这不仅能帮助团队自信地交付产品，还能为最终用户维持其质量。
质量的改进永无止境。每一次循环的收获，都是下一次循环的改进：事故带来更好的监控与告警；后期才发现的 bug 促使测试更早进入流水线；用户抱怨让下一次的需求更清晰；性能问题推动 CI 中加入负载测试。
SDLC 是一个循环，而不是一条直线——质量在每一次迭代中不断增长。核心心态是持续改进（Continuous Improvement）：回顾会议驱动流程变更、无指责文化让人能坦诚评估、指标用于指导优先级（而非惩罚团队）。正如亚里士多德所说："质量不是一种行为，而是一种习惯。"
正如你所看到的，质量最好通过团队协作来实现。在下一个单元中，我们将看到如何在团队中打造质量文化。
打造质量文化（02 Create a Culture of Quality）
本单元探讨如何打造一种把质量融入每个团队 DNA 的文化——在自身情境中工作、排定优先级、跨团队沟通，并始终牢记用户。
学习目标 — 完成本单元后，你将能够：
- 定义什么是"质量文化"
- 解释如何在组织情境中工作
- 描述排定质量工作优先级的策略
- 识别跨团队沟通质量的方法
什么是质量文化？（What Is a Culture of Quality?）
质量取决于"感知"（perception），这使它难以被精确界定。正因如此，构建一种文化才尤为重要——在这种文化中，团队讨论、协作、理解并重视质量，将其视为整个 SDLC 中不可或缺的一环。一家公司眼中的质量，可能并不等同于另一家公司眼中的质量；此外还有用户要考虑，组织必须理解他们对质量的愿景。
虽然可能不存在对质量的唯一定义，但有一些通用的活动是所有团队和组织都能开展、用以培养质量心态的。质量文化，就是一个质量是每个人的共同价值观、而非某个部门的职责的环境，其特征包括：
- 质量被公开讨论——而不是被默默指责
- 错误是学习的机会——而不是职业风险
- 每个人都感到有责任——开发、运维、业务、QA 都一样
- 流程支持质量——而不是妨碍它
- 质量是主动的——内置进去，而非末尾检查
需要提醒的是，打造质量文化要求团队或组织的核心发生转变。某些工具或方法论当然能帮助构建文化，但仅靠实施它们并不能改变文化。不要依赖单一解决方案，而应把下面的行动与你最好的资源串联起来，培育一种以质量为中心的文化。文化会把战略当早餐吃掉——如果团队不重视质量，再好的工具也会失效。
在自身情境中工作（Work Within Your Context）
环境造就情境。在软件开发中，这些环境因行业、组织、团队和项目而异，它们共同构成了独特的情境，指引着团队如何对待质量。因此，团队必须深刻理解自己工作的范围与约束，并据此调整工作方式。
让我们探讨几个变量，看看它们会如何影响团队的质量工作：
- 行业（Industry）：不同行业的质量要求各异。例如，医疗健康的关键性质意味着它有严格的监管，因而更倾向于规避风险。
- 组织（Organization）：在组织层面，对质量的感知至关重要。组织的规模、历史与领导力会影响公司对质量的重视程度，进而影响投入其中的资源。
- 团队（Team）：虽然整个团队都对质量负责，但个人的优势与专长会影响具体职责的分配。例如，拥有一位精通某类测试的质量工程师的团队，可能比没有类似专家的团队承担更多该领域的职责。
- 项目（Project）：每个项目都有不同的需求、预算和时间线，从而产生不同的优先级。
没有放之四海而皆准的质量方法——你的质量策略取决于团队规模、行业监管、风险容忍度、发布节奏以及遗留系统等。你的风险容忍度是横跨所有这些层面的一个因素：有些行业的风险阈值更高，因为后果不那么严重；有些组织的风险容忍度则受到过往风险关系后果的影响。要了解团队可能面临的风险，可以开展风险评估，甚至把风险分类（如技术类、预算类或组织类），从而更好地理解团队对特定项目的容忍度。理解这一情境并就风险达成共识，就是在为团队培育质量文化。
从最佳实践中汲取灵感，但要实施适合自己的——不要生搬硬套（cargo-cult）那些并不适合你的流程。
排定优先级（Prioritize Your Efforts）
虽然"对一切都进行测试和信息收集"听起来很棒，但没有哪个质量团队能覆盖那么多测试。资源是有限的，团队必须就"把精力聚焦在哪里"做出关键决策。运行大量测试并不能保证质量的提升；运行正确的测试才能。
SDLC 中的干系人必须协作，确定"测试什么、如何测试"。对团队而言，这通常意味着思考两个问题：
- 为了让产品成功，哪些功能必须正常工作？
- 问题最常出现在哪里？
针对这两个问题的答案，最大化团队的资源。基于风险的优先级排序要点如下：
- 哪些故障的影响最高？（收入损失、安全漏洞、用户信任）
- 哪些故障最常发生？（不稳定的测试、反复出现的 bug、部署问题）
- 哪些问题最容易修复且回报最高？（能快速积累势头的"速赢"）
聚焦关键路径：核心用户旅程优先，其次是影响收入的功能，再次是安全与合规要求，最后才扩展到边界情况和锦上添花的需求。质量中的帕累托法则（Pareto principle）告诉我们：80% 的风险往往来自系统中 20% 的部分——找到那 20%，优先保护它，然后再逐步扩展。
跨团队沟通（Communicate Across Teams）
从需求到回顾会议，干系人需要跨团队的开放沟通，才能提供最高水平的质量。例如，有些团队偏好开放式工位，以促进更好的协作与互动。无论你的物理办公环境如何，围绕进展、障碍和困惑的频繁沟通都能让质量走到台前，让每个人都能参与解决问题。对许多团队来说，这些会议采取每日站会（daily stand-up）的形式，成员分享各自的工作并设定当天的优先级。
开放沟通的一部分是提问。无论是需求还是 bug，澄清期望与问题都有助于防止未来的误解。此外，来自好奇干系人的提问，能在问题变成生产环境 bug 之前就揭示出疏漏。
打破孤岛是质量的关键：开发与运维共享生产质量的归属，业务与开发共享对需求的理解，QA 与开发协作测试而非对抗式检查，支持与开发让用户报告的问题进入质量待办清单。沟通实践包括跨团队站会或同步会议、共享仪表盘（让每个人都看到相同的指标）、无指责的事后复盘、质量实践社区，以及轮岗（开发做支持、QA 参与设计评审）。
最后，沟通还意味着分享专业知识。随着质量融入 SDLC 的更多环节，角色和职责将需要更广泛的知识储备。可以安排技能与知识分享会，例如 Lunch and Learns，让来自运维侧的质量工程师牵头，与更大的团队讨论某项具体的测试活动。当团队真正沟通起来时，问题会在交接之前就被发现，而非之后；上下文不会在工单流转中丢失；信任取代了指责；质量成为一个共同的目标，而非一场谈判。
牢记用户（Remember the User）
质量存在于观察者的眼中——在软件的世界里，这个"观察者"就是最终用户。技术质量并不等同于用户感知的质量：100% 的测试覆盖率并不等于用户满意；零 bug 并不等于产品可用；性能飞快也并不等于工作流程合理。
在规划时，要思考包容性的、真实的用户画像（persona），以获得对产品及其实际使用方式的真实图景。有时你会发现用户以意想不到的方式与产品交互。通过实地观察（field observation）等方法，去发现这些意想不到的用法，从而获得对用户体验的宝贵洞察。
以用户为中心的质量问题包括：
- 用户能否轻松地达成目标？
- 体验是否一致地贯穿各个触点？
- 错误提示是否能帮助用户恢复？
- 产品是否对所有用户都无障碍（Accessible）？
- 它能否在真实的设备与网络上可靠运行？
每一项质量实践都应追溯到同一个问题："这能否让用户的体验变得更好？"如果不能，就去质疑你为什么在做它。指标应该衡量用户的结果，而不仅仅是代码健康度。项目早期的沟通与协作，是为了在流程结束时把最好的产品交付给用户——SDLC 就是理解需求、按需求构建功能、再通过产品交付给用户。这一共同目标把不同的干系人和群体统一在共享的质量愿景之下。
总结（Wrap-Up）
随着软件开发不断演进与加速，质量有赖于协作。团队协作的方式要求共享职责、转变文化，从而把最好的产品交付给最终用户。
打造质量文化是一段旅程，而非终点。核心要点如下：
- 质量属于每个人——开发、运维与业务
- 左移——在问题更早、成本更低的时候捕获它们
- 在情境中工作——让实践适配你的现实
- 排定优先级——先保护关键路径
- 沟通——打破团队之间的孤岛
- 牢记用户——质量等于用户体验
- 持续改进——每一次循环都滋养着下一次
从小处着手，积累势头，持续改进——质量文化会随着时间复利增长。
文章来源：Trailhead - Quality Teams in the Software Development Lifecycle