目录
PDCA模型中，只有分析了根因才能继续改进提升。研发抵触心理沟通
QA和QC的区别：
QC是类似于测试人员，QA是质量管理人员。
QC是警察，QA是法官。警察是负责抓坏人，但是法官要负责提前普及法律知识。
一：各类指标要求：
任何指标制定要考虑：
指标合理性、
看到做哪方面改进措施 ；
高了低了会代表了什么，需要做什么改进？
一般指标有
reopen率：5%：目标是0；
代码千行bug数；
工作量偏差=（实际工作量-计划工作量）/（计划工作量）*100%
各项指标：参考
研发质量度量_研发质量指标_Roda的博客的博客-CSDN博客
reopen说明：
每天统计reopen数量、reopen rate：
reopen rate不量化，只看 趋势，只要趋势向上走就是高风险，就上升解决。
reopen rate用总的，不能用每日reopen rate：
总的：Reopen Rate=reopen times合计/（缺陷总数 + reopen times合计- reopen未关闭的总数） ;
（每日repen rate值：
当天reopen总数/当天新产生的bug（总bug=当日reopen总数 +每日新增bug数））
reopen数量趋势下降，目标是0，对reopen 0容忍，可以修复的少，但是不能重复修复；
action：每天通晒reopen对应研发和测试人员，趋势上升就警告，趋势下降不警告；
reopen 数量，详情列表：开发或者功能模块；每天是多少，前3个整改；
到UAT环境上：
建议：流程上：研发改完-->测试人员验证通过后->给客户的测试人员验证。
每日reopen数据跟踪:
【每日reopen数据】
reopen：个，当日reopen率：%，周reopen率：%，
【原因分析】
当日A方原因占比：%，当日B方原因占比：%、
当日A方原因占比最高原因及比例：%，当日B方原因占比最高原因及比例：%；
【预警】
1、周reopen率：15.17%（超过预警线15%），原因：其中5天内有1天超过15%（3月22日:26.92%）。
研发类：
【研发未填写原因】共4个bug，相关研发： AA:2个，BB：2个
【reopen多次晾晒】：
reopen n次，共m个bug，研发：，原因：
【关注模块占比】
A模块：
B模块：
【每日新增bug数】 （Critical: ，High: ）
【每日关闭/取消bug量】
UAT bug情况及质量跟踪事宜
bug收敛情况（每日新增和每日关闭/取消数据对比）、bug总数和预期的趋势图对比、模块bug风险、延期风险、reopen rate（日 、周、累计）、reopen多次、reopen原因必须填写、bug长时间未解决的；
针对bug多的模块及reopen多次的，安排人员复测；（如果原来没有安排测试人员复测，则需要安排）；
代码问题解决方案：
代码review、安排复测、架构师将难的风险提前发现；
每日线上数据统计汇报；
代码review和代码扫描的区别：
代码review就是评审开发的代码，一起看开发代码写的对不对，质量高不高。代码扫描一般是用工具扫描代码有没有漏洞，有重合的地方。
一个人工，一个工具
二：流程要求：
总流程：需求宣讲->研发且冒烟用例通过后->测试案例通过率100%->给客户演示。
具体每个环节的执行过程，请见下面详情：
研发模式：
瀑布：缺点耗时长，下一个环节要等待上个环节结束了才能开始，可能做完了需求又变更了。
敏捷：小步快走，欢迎客户变更，迭代快交付快，适合快节奏的研发。
建议：如果项目时间紧张，可以综合两种研发模式的优点，需求不用等到所有模块都已经结束了才能开始研发，可以确定一个模块后，该模块开始研发，后续有小的变更，走项目变更流程，或者另外确定CR进行研发。
需求定稿后才能开始研发。
各个环节的准入准出标准：
需求：需求文档无遗漏，定稿后和研发、测试人员宣讲，如有意见修改定稿后再通知大家。
测试准入标准：功能的冒烟用例通过，否则打回。
准出标准：用例执行率100%，用例通过率100%，遗留bug被三方（QA、BA、研发leader）同意遗留。
交付后：
定期关注线上bug情况：reopen数量、线上单日bug数、线上长时期未解决的bug。
reopen数量：目标是0，reopen是态度问题。
reopen率：呈递减趋势
线上单日bug数：统计数量，并收集原因归类统计，观察改善情况。
线上长时期未解决的bug：定位原因。
三：QA推动质量改进事宜：
进入项目后了解项目情况：从宏观入手了解实际行动的不足之处，不要上来就低头做具体的事情，可能方向会错。
收集信息：
针对不同的人问不同的问题,了解项目事情时：可以多问，鼓励对方多说，收集项目信息。针对不同的角色问不同的问题：
需求人员：如何收集需求，收集后的信息如何跟研发、测试人员同步，需求有变更时信息如何通知到其他人，工作过程中的痛点有哪些？
研发人员：如何维护代码版本、开发到什么程度提交到测试的（是否联调过且通过、是否自测过）、工作过程中有没有痛点
测试人员：收到的需求信息是否和验收时客户的信息一样，转测时冒烟用例有没有通过，测试用例、bug怎么管理的，测试过程中有什么痛点。
制定解决方案
制定解决方案后，先内部拉管理层确定方案，听取领导的建议，进行调整。
确定方案后，定具体执行方面的责任人、解决时间，定期跟踪推进。
人员沟通方面：
QA人员因为需要和各个岗位的人沟通事情，要注意方式方法。因为人都有懒惰行，说服别人做事非常难，说服一群人做事难上加难。
沟通前：不要和对方对立，和对方站在一起，如果无问题就过，有问题，要讲改善对对方工作的益处。切忌：上来就说对方做的不对，会引起对方的敌意。还可以借力推动，通过其他岗位人员的反馈，推动事情发展。
具体执行相关的人员，不要说太多信息，只需要讲领导做的决策即可。
当发生争论时，不要陷入对方设置的圈套，坚持原则并解释监控数据的意义，获得管理层的支持。
注意事项：
1、遇到人和管理上的事情，推不动的，不要自己闷着，要升级到PM等管理层去推动。
2、不能通过降低标准提升质量，而是要通过严格改进，提升质量。
3、要从管理层考虑：对客户负责，不要被具体执行者忽悠了。
4、关于缺陷是质量问题，reopen是态度问题，因为reopen是修复不通过、因为自测不通过导致。
四:做“救火队长”提升质量的问题清单
很多项目做到最后交付了，才发现质量不达标，客户不满意，临危受命提升质量，该从哪里下手，先从下面的问题清单作为入口，了解项目详情：
客户
客户测试出来的bug有哪些，进行bug分析，判断是哪个环节出的问题。
需求人员
客户的需求是否经常变更，如果变更目前怎么处理？
需求是如何传达给研发、测试人员的，是否有正式的需求宣讲？
针对测试人员
流程标准类：内部测试流程有哪些？如果没有，那么转测通过标准、测试通过标准是哪些?
bug：怎么管理的，是平台上还是excel上？最好是前者，可以上传更全面信息、方便跟踪（追溯）、管理；
资料类：测试用例、测试报告、测试方案、测试计划，有没有，如果没有、需要补充，给与模板。
测试内部是怎么管控质量的？
即将交付之前：
要查看还有哪些功能交付有风险、提前报出来，交付物清单情况、交付物格式是否符合要求；
你们自己对工作协同上有什么不满意之处？
研发人员
代码及版本：如何管理的，会不会出现代码覆盖情况，如果出现，怎么管理的，是否有相应处罚？
bug处理：是怎么管理的，bug状态流转研发是否清楚、bug处理时间多久会告警、bug reopen是否有监控及惩罚？
工作中的痛点、协作上的困难有哪些？
五：学习
TQM和6sigma。
TQM：
如今日本产品以精细著称，日本企业普遍都具有“匠人精神”这样的文化基因。在TQM的理论基础上，通过不断的实践总结，形成了自己的一套质量管理的心得和方法论。比如丰田生产模式（精益生产）、改善、QFD、QC小组、5S管理……
TQM(全面质量管理)的核心，概括起来就是“三全”、“四一切”。
1. 全面质量的管理
全面质量管理所追求的“质量”不仅仅是指提交给顾客的产品（这里所指产品是企业提供的产品、服务的统称）质量，还包括成本质量、交货期质量和服务质量。这些质量的全部内容就是广义的质量概念，即全面质量。
产品质量+成本+交货期+服务=全面质量
2. 全部过程的管理
产品的形成是包括企业一系列活动的整个过程。这个过程包括市场调查、研究、设计、试制、工艺与工装的设计制造、原材料供应、生产制造、检验出厂和销售服务。用户的意见又反馈到企业加以改进，这整个过程可看作是一个循环过程。产品质量的提高依赖于整个过程中每个环节的工作质量的提高，因此，质量管理必须对这种全部过程的每个环节都进行管理。
3. 由全体人员参加的管理
产品质量的好坏，是企业许多环节和工作的综合反映。每个环节的每项工作都要涉及到人。企业的人员，无论是前方的还是后方的，是车间的还是科室的，没有一个人不与产品质量有着直接或间接的关系。每个人都重视产品质量，都从自己的工作中去发现与产品质量有关的因素，并加以改进，产品质量就会不断提高。因此，质量管理，人人有责。
四一切
1. 一切为用户着想
产品生产就是为了满足用户的需要。因此，企业应把用户看作是自己服务的对象，也是为人民服务的具体内容。为了保持产品的信誉，必须树立质量第一的思想，在为用户提供物美价廉的产品的同时，还要及时地为用户提供技术服务。
2. 一切以预防为主
一切以预防为主全面质量管理强调事前预防，事前把所有可能出现的差错和可能遇到的风险等进行系统的识别、评价，并进行防差错设计，将所有的差错、风险消灭在事前。全面质量管理强调事中预防，事中进行持续的监视、测量、反馈和对问题的及时调整，将所有的差错、风险消灭在萌芽状态。第一次就把事情做对，永远是成本最低的。好的产品是设计和生产出来的，不是检验出来的。
3. 一切用数据说话
“一切用数据说话”就是用数据和事实来判断事物，而不是凭印象来判断事物。
收集数据要有明确的目的性。为了正确地说明问题，必须积累数据，建立数据档案。收集数据以后，必须进行加工，才能在庞杂的原始数据中，把包含规律性的东西提示出来。加工整理数据的第一步就是分层。分层在全面质量管理中具有特殊的重要意义，必须引起我们的重视。对数据进行分析的基本方法是画出各种统计图表，例如：排列图、因果图、直方图、管理图、散布图，统计分析表等。
4. 一切工作按PDCA循环进行
PDCA循环是全面质量管理的思想方法和工作步骤。P是计划，D是实施，C是检查，A是处理。任何一个有目的有过程的活动都可按照这四个阶段进行。
第一阶段是计划，包括方针、目标、活动计划、管理项目等。
第二阶段是实施，即按照计划的要求去干。
第三阶段是检查，检查是否按规定的要求去干，哪些干对了，哪些没有干对，哪些有效果，哪些没有效果，并找出异常情况的原因。
第四阶段是处理。把成功的经验肯定下来，变成标准。以后就按照这个标准去做。失败的教训也要加以总结，使它成为标准，防止以后再发生。没有解决的遗留问题反映到下一个循环中去。
六：根因分析
PDCA模型中，只有分析了根因才能继续改进提升。
研发抵触心理沟通
研发对分析bug的抵触心理的回应：
【目的】分析根因不是为了追责而是为了改善提升，
【益处】分析根因，就可以知道需要在哪里提升改进，进而可以节约人力、时间，对研发、客户、项目都是有益无害，
做这个事情期间，大家都得放弃被追责的心态，我们只是在解决问题、提升质量~
不是我们做的不够好，是可以做的更好，
不是我们不够优秀，是我们可以更优秀。
各个角色的问题根因类型
| 问题原因大类 | 问题原因小类 | 改进措施 |
| 需求 | 需求文档中无 | 补需求，后续BA人员和客户加强沟通。 |
| 新增需求 | 走变更流程，变更委员会是否同意变更，如果同意则变更，需要的时间多久，跟客户也要争取，不同意则不变更。 | |
| 研发 | 代码能力不行 | 培训提升，代码review |
| 自测不够充分 | 研发充分自测，UAT阶段最好测试通过后，再交给客户方 | |
| 状态流转错误 | 宣贯平台bug流转操作步骤 | |
| bug修复后未备注版本号、未说明影响范围 | 1、bug修复后备注版本号 | |
| 2、bug中说明影响范围 | ||
| 测试 | 缺少用例 | 测试用例场景设计全面，补充对应用例 |
| 用例缺观察点 | 补充用例观察点 | |
| 有用例未执行、有用例已执行未发现问题 | 加强用例执行管理 | |
| 测试环境已经发现该问题且已经验证通过关闭，但是UAT环境仍然有该问题 | 定位下： 1、代码被改动，引入新问题 2、改好的代码未发布到UAT环境，代码分支管理：定位下代码是否被覆盖 | |
| 客户方 | 验证人员状态流转错误 | 宣贯平台bug流转操作步骤 |
| 操作错误（例如未杀掉进程重新登录） | 验证时正确操作 | |
| 环境 | 机型差异 | 测试环境补充缺失的机型 |
| 环境配置差异 | 测试环境和生产环境尽量一致 |
166
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
