在业务早期发展阶段，主要是产品驱动、研发和测试互相配合。不同的测试方法是验证和保障交付质量的手段，而不是构建质量体系的基石。测试的努力带来的更多是一些“安全感”，而非安全保障。因此，要做到高质量的交付，就需要回到质量的本质，好的产品依赖于其底层设计。质量设计核心思路是“好的质量是设计出来的，而非测试出来的”。保障质量需要尽可能地“设计先行”，在前期充分讨论需求，严格把关设计，把质量问题在源头解决。与之相对应的则是，不同于早期阶段的完成测试动作，团队需要从交付质量保障转入质量共建。
看图说话，容易得出：大部分缺陷都是早期引入的，同时大部分缺陷都是中晚期发现的，而缺陷发现的越晚，其修复成本就越高。因此，为了降低缺陷修复成本，我们期望在更早的时间发现缺陷。
测试的左移与右移指的是，让质量保障尽早地发生在整个 SDLC（产品开发生命周期），同时确保稳定性得到持续保障。在需求阶段，测试左移的目标着力于验证需求质量，包括方案验证、功能验证、支撑性验证等，由此分析需求的完整性，及时发现设计中可能存在的问题。质量保障团队有明确的需求评审规范，测试会在项目需求阶段介入，避免等到实际测试阶段时才发现问题，导致修复成本过高，无法高效提交项目。
需求呈现出以下三个粒度：
史诗故事 > 特性故事 > 用户故事
史诗故事 Epic：粗粒度的描述需求，通常需要多个迭代才能完成，主要用于版本规划时记录和跟踪该功能
特性故事 Feature：也叫主题故事，是一系列相同主题用户故事的集合，主要用于迭代规划、优先级排序和整体估算
用户故事 Story：迭代开发的最小单元，是较细粒度的需求描述，主要用于迭代交付过程中的估算、跟踪和管理
测试人员可以参与需求评审：
针对功能需求，测试人员先验证需求是否有效，包括需求价值确认，需求涉及场景是否完备，与现有业务逻辑是否有冲突
针对功能需求背后的支撑性需求进行澄清，确认支撑性需求的范围、验收标准、测试方式等；此外还需要考虑用户体验
考虑需求的拆分是否合理，是否便于估算和迭代管理
测试左移之所以重要，是因为我们要在缺陷引入的最初阶段就发现它，把缺陷扼杀在摇篮里，而不是等着它像雪球一样越滚越大。而这里的误区在于，测试左移要求的测试活动尽早介入，而不仅仅是把测试人员进行左移。因此，团队里的每个成员，都需要有测试左移的思想，都可以从一开始就绷紧质量这根弦，确保每个人的工件质量。对中小公司或团队而言，如果测试左移、开发自测，或者产品运维自测上线，那么我们是否还需要测试呢？这个问题我觉得关键在于测试的价值与产出的呈现，在于项目对测试的依赖。举例来说，项目的左移意味着开发要在较好的测试环境中进行测试，但这对开发而言是具有困难的，如果测试可以提供平台化工具、保持流程通顺，并提供验证、引流的能力，协助项目左移，那这不失为一个很好的解法。
而在需求的质量保证活动中，测试人员也需要时不时换帽子，有时可能是终端用户，有时可能是产品经理，也有时可能是产品负责人。不管戴什么帽子，保证各个工件的质量，以及各工件的顺畅集成，都是测试人员可以关注的事。质量相关，我们责无旁贷。
质量活动方面，测试人员可以落实测试计划了，如各种测试活动的安排，测试效果的评价，测试的重点和难点，测试阶段的输入和输出等，在这个阶段都可以确认了。
在开发阶段，质量保障团队需要充分了解开发的代码框架，从而更好地评估改动范围和需要回归的内容。同时，质量保障团队可通过提供自动化测试脚本的方式，让开发团队在前期加强自测，避免在后续收到提测包时仍然有基础问题存在。此外，质量保障团队与开发团队会在共同的规范下有序推进开发工作，这也是测试左移的关键一步。“目前质量保障团队已经确立了开发质量规范，制定动作、明确责任人。其核心目标是将问题在初始阶段解决，避免在产品提交后重复工作。”
在运营阶段，质量保障团队会持续监控产品在生产环境下的运营体验，确保产品在实际环境、场景下，其功能和体验都能符合用户预期，而这也是测试右移的关键步骤。此时，质量保障团队会通过埋点数据、生产监控、用户反馈等措施，与运维团队一起完善监控体系，发现系统可能存在的漏洞并及时修正。例如，对用户名、访问时间、资源地址进行监测，判断是否符合规范和要求；对访问频率过高或者其他异常情况进行监控，若符合警告规则，系统可通过邮件等方式通知相关人员，并帮助其快速定位问题。
质量数字化管理的本质是将需求质量、过程质量、交付质量通过数字化指标抽象出来，并以此为依据完成质量保障。例如，通过大量元数据的收集和管理，团队可快速发现问题、定位问题，这其中涉及到数字化指标包括如过程质量中的 demo 次数、转测次数等；交付质量中的 UT 覆盖情况、自动化覆盖情况、缺陷情况等。
其中，需求质量主要指的是在包括原型图、PRD 文档、交互设计、技术方案、测试用例等基础上，质量保障团队从不同于产品、研发的角度理解需求设计，同时根据已有的数字化指标提出建议并协同产品、研发团队进行修正。在项目启动阶段，质量保障团队就参与到整个设计过程中，充分汲取产品、研发等不同岗位角色的需求，降低后续产品的过程风险和交付风险。
“对于过程质量和交付质量而言，一方面是通过测试的左移右移确保整个产品从研发到交付全过程保持质量可控；另一方面则是构建一系列标准化门禁，如研发架构侧资损防控标准化设计检查清单、验收清单，以及 QA 侧的 Sign off 条件、严格上线验收清单，包括账务比对清单、用户交互验收清单等。不能达到设计预期的产品将无法完成交付。”
大质量模型指的是“持续”的质量保障能力，可以从“质量金字塔模型”和“一切皆代码”层面理解。如下E2E Test
其中，质量金字塔模型在不同公司均有实践，这套理论模型在 质量保障体系中同样有所应用，包括从 UT、API、UI 到 E2E 都是不可或缺的部分，但是在更为坚持的观点在于，一切理论的背后都是代码，对于质量的保障实际上最终要落到代码层面。
快速的高质量交付，意味着持续的全回归测试，“智能化测试”在其中扮演了重要角色，能够实现精准和高效。精准，是通过代码去度量影响范围；高效，则是通过代码如 UT/E2E 等来实现快速测试。
精准测试体系中，测试用例对应的代码逻辑精确而完整的实现了全自动化的追溯和存储，因此赋予了测试用例深入分析的基础能力。在精准测试的用例魔方中，目前存在三个面（随着后续功能的增加，将增加分析的面）：即回归测试用例选取、测试用例聚类分析、测试用例最小化，同时辅之以智能缺陷定位技术。当测试用例与代码的追溯关系建立的时候，测试魔方的核心功能区即同步构建出来。为数据的多角度分析，提供了丰富的资源素材库。
为持续提升测试精准度和效率，质量保障团队会把测试专项能力向服务化能力转型，建立自动化为主的测试能力，减少手工测试和手工操作。目前，测试自动化主要包括自动化环境创建与部署、生成测试数据、执行自动化测试，生成测试结果与日志；此外，也会对测试相关结果进行自动化监控与分析，自动生成测试报告，便于进行测试定位失败原因与快速修复。
质量文化
质量文化被抽象为质量规范、质量度量和技术延展。随着业务更加成熟、规模不断增长，质量文化需要不断强调、落地和迭代，这就需要制定一些规范来保证落地效果。这里的规范不是强制要求大家一定要做什么，而是为了大家在不同的工作阶段都有据可依，知可为、知不可为。质量规范体现在产品需求阶段，有针对性地构建 PRD 规范、技术方案规范，在后续的开发、测试、上线等阶段构建开发规范、提测规范、发布规范、运营规范等。
同时，在不断提高产品质量的过程中，如何评估质量的效率也颇为重要，质量保障团队将其抽象为质量度量，包括需求度量、开发度量、交付度量、运营度量、故障演练度量等维度，确保大家在关注质量的过程中，也要同步关注效率。
“建立质量文化，还需要关注对质量技术的研究，这是确保质量保障体系在团队最终落地，并提高质量效率的基础能力。”团队关注新的质量保障理论和技术层面的探索，质量不仅是后台支持保障，也是前沿技术的落地场景。
例如，随着业务快速发展，传统的自动化测试已经不能满足快速变化的业务需求，自动化前置是目前研究的重要课题。“为了持续提升研发交付效能，质量保障团队将进一步加强人工智能技术在测试领域的应用，其本质是结合 AI 算法和测试数据对测试多环节进行针对性的优化，达到对业务需求更强的适应性和响应能力。”
阿里 现在在做 测试用例自动生成：用技术手段减少测试人员的个人能力差异的影响。
质量体系建立任重道远。
