全面质量管理体系方案

质量体系调整方案

原因

业务不断增加，使得系统复杂度不断增加，回归测试流程越来越长。而对于质量、稳定性、性能以及快速交付能力的要求会进一步提升。
如何成为更好的高效能团队，使得稳定性不因为交付吞吐量的提升而下降，同时让整个团队共同担负起质量的责任，是从去年以来，我们一直希望去做到的。
很显然我们需要进一步提升自动化测试的程度，提升自动化的覆盖面，进一步清晰化统一化自动化的技术体系，为未来的测试标准化平台化做准备，使得我们可以从大量手工测试、质量与研发体系关联不强，逐渐到质量共责、提升自动化，到慢慢的测试自动化（自动化测试与测试自动化的区别），我们还有很多路要走，但事实证明传统的模式要推进这样的质量改革效能是很低的。
我们需要跳出原有框架，重新审视我们的文化和愿景，制定新的方针与方案，并且不断的优化，才能让质量让测试更进一步，使测试不仅是测试，而是完善提升坚固我们质量体系的核心关键岗位。
随着我们组织高效能化的提升，产品的设计、实现和发布会由不同组织更高效地实现，因此QM（质量管理）成为来将不同的环节与组织衔接在一起纽带。
我们要以价值链为主导，价值链中的每个组织都可以实现自我价值的最大化，价值链的起点是需求，终点是客户，环环相扣，不断迭代优化。

长期目标

我们的整个质量体系将像TQM进行转变，TQM（Total Quality Management）全面质量管理，是对一个组织以产品质量为核心，以全员参与为基础，目的在于通过让顾客满意和本组织所有者及社会等相关方受益而建立起一套科学高效的质量体系，从而提供满足用户需要的产品的全部活动，达到长期成功的管理途径。是改善效率及质量的一种重要方法。
顾客满意：
顾客即供应所提供产品的接受者，可以是组织内部的，也可以是组织外部的。
附加价值：
用最小的投入获取最大的功能价值，追求组织最大的经营绩效和个人最大的工作绩效。
持续改善：
建立以PDCA回圈为基础的持续改善的管理体系。

• 建立持续创新和改善的目标；
• 采纳这样一种哲学，我们不能容忍老毛病；
• 用统计证据说明质量已经做进去了；
• 用统计方法发现问题所在；
• 改进监督，不仅注重产品质量，而且监督所有各类人员的行为正确性；
• 驱除恐惧，使大家对指出问题和接受询问时不感到害怕；
• 打破部门间、研发、测试及产品沟通的障碍，提高沟通有效性；
• 限制使用只规定效率的工时定额，这种定额只能使大家不顾质量同时限制产量的提高；
• 鼓励敬业精神；
• 实行一个保持变革和创新的培训计划；

影响群体

名词解释

QM（Quality Management-质量管理简称），是对确定和达到质量目标所必须的全部职能和活动的管理。包括质量方针目标的制订及其组织实施，也包括质量控制活动。在质量方面指挥和控制组织的协调的活动（通常包括制定质量方针和质量 目标以及质量策划，质量控制，质量保证和质量改进）。
QA（Quality Assurance-质量保证简称），是指使人们确信某一产品、过程或服务的质量所必须的全部有计划有组织的活动。这种活动的标志或服务的质量所必须的全部有计划有组织的活动。这种活动的标志或结果，就是提供"证据"，目的在于确保用户和消费者对质量的信任。
QC（Quality Control-质量控制的简称），的为保持某一产品过程或服务的质量所采取的作业技术和有关活动。一般指为保证产品质量达到规定水平所使用的方法和手段的总称，是QM的组成部分。
QMBP（质量管理业务伙伴），会深入到负责项目的全流程，从协助需求把控到进行运营质量把控跟踪，出具测试用例，思考各种边缘情况、极限情况下系统质量问题并进行尝试，记录并跟踪项目运营质量问题，并与开发、产品沟通优化提升方案。
QMTP（质量管理技术伙伴），更专注于为QMBP提供自动化测试技术解决方案，以及提升自动化测试覆盖率，也可直接与项目小组进行对接，对成熟稳定的系统提供自动化质量保障体系方案。

测试的影响

过去我们对测试的定义更偏重于QC，更多的偏重于质量控制，但是我们希望构建更加高效能的质量责任共担的组织。如果测试继续仅仅是QC的定位，这将无法使整个组织都来关注质量。
让测试人员远离生产一线，实际上是将测试人员角色从保姆变为教练，从仅关注产品质量到关注整体质量。按照逻辑讲，研发人员应该比测试人员更知道问题所在。当组内所有人员都开始关注质量时，那我们就可以消灭现在的测试人员了，测试人员则从更高的层面为我们的整体质量提升做出贡献。因此在这套体系下，测试人员的使命就是消灭专职测试，这似乎是一个悖论，但实际结果就是这样。
质量人员将转变为QM
我们需要将QC功能交付给研发部门，解决研发与QC责任不清的问题，所有研发人员都是QC了。这时候以往的QC岗位升级为QA与QM，主要支持研发部门进行质量体系的提升，测试部门的工作与职能将发生转变：

• 对迭代关键节点的把握
  • 该小组对于产品经理提前提供迭代需求（2周的迭代，需提前1周提供用户故事）
  • 迭代会议时同步提交测试用例，与用户故事一起过审（试行）
  • 迭代结束时研发团队提交基于用例的测试报告
  • 发布前完成验收测试
  • 迭代内代码质量报告
• 工作产出物
  • 测试用例
  • 测试用数据列举
  • 测试工具规划及需求提交
  • 验收报告
  • Bug提交
  • 自动化测试脚本
  • 生产问题报告（故障、客服、运营问题）
  • 探索性测试、破坏性测试报告并完善用例
  • 质量改进方向
• 工作验收物
  • 迭代用户故事（迭代会前一周与组内SM一起看，是否基本符合次周召开迭代会的要求 – 做什么，做到什么程度，是否有优先级，细腻度是否够，需求是否清晰）
  • 自动化测试报告
  • 研发小组测试报告
  • 代码质量报告（通常以静态为主，有code review时跟进改进结果）
• 新的工作职能
  • 跟进追踪质量全过程，协助团队提升整体质量，从需求到生产问题的跟进记录
  • 对产品进行各种探索性测试、破坏性测试，完善测试用例
  • 质量问题分析报告
  • 提升测试自动化程度
  • 降低测试质量缺陷比及生产质量缺陷比
  • 提升生产问题处理效率
  • 提升运营问题处理工具化标准化比例

研发的影响

研发将不再是完成开发后就将质量问题交给了测试，更多的测试工作将由研发自己完成。研发需根据测试用例完成测试报告，测试报告的内容由质量人员抽样验收以达到出口标准，测试将不再接受没有组内测试报告的版本提交（鼓励更多地通过自动化的方式完成测试）。
还记得曾经的敏捷课程分享上，武士与大师的故事吗？
武士：是的，大师，但是如果没有一个专职的测试者角色，我们如何才能相信有足够的测试呢？
大师：测试属于必须完成的任务，因此测试会由团队来完成。团队会决定进行何种程度以及何种限度的测试。
武士：如果没人想做测试怎么办？如果大家都只想坐下来编写代码怎么办？
大师：那么你最好要找喜欢测试的员工，确保他们成为你团队中的宝贵成员。

组织调整方式

现有测试同事会以质量管理顾问的形式与小组关联，测试同事与各小组可双向选择，一个小组从项目角度选择质量顾问。
QM同事会分为两层，如下图：

迭代节拍

 

短期目标

1. 每个迭代的用户故事都要求产品提前二分之一迭代发出来
   1. 看是否有特别不清楚的内容
   2. 看是否需要跨组协同（需要则提前在其他组迭代会前与其他组协商需求）
   3. 保障迭代会时需求质量不会太差
   4. 提升迭代会效率
2. 用户故事更标准
   1. 团队所有人都能理解
   2. 分用户场景分情况
   3. 可验证可测试的
3. 测试用例沉淀
   1. 常规测试
   2. 破坏性测试
   3. 混沌测试
   4. 回归测试可直接参考
4. 需求沉淀并有良好节奏（基于Tuleap）
   1. 需求做到有迹可循
   2. 变更做到有迹可循
   3. 从过去的需求中提取出模块化的东西
   4. 需求池不至于遗失需求
5. Bug可追溯（基于Tuleap）
   1. 什么时候发现的
   2. 谁修改
   3. 结果怎么样
   4. 短期不修复的bug不至于遗失
6. 团队自行负责质量，QM只做验收把控
   1. 通过自测缩减中间环节
   2. 保持团队高效能
   3. 提升整体质量控制
7. 测试环境开始，所有发布基于Jenkins，不再手动至测试环境发包
   1. 避免手工发包代码覆盖
   2. 测试的发包也基于版本
   3. 研发、QM都可以根据自己需求在特定时间触发发版
   4. 代码静态扫描提升代码质量
   5. 每日构建保证代码质量的可靠，有问题及时发现
8. 进一步提升质量与效率，并提升测试的自动化含量
   1. 基于RM开始搭建自动化测试平台
   2. 对于稳定的业务尽量做到接口自动化