聊聊质量----

 2019年10月12日在厦门有某公司的6位质量管理同仁一起共进晚餐，席间讨论多个话题。10月14日，这些有心的朋友整理了问答记录，我做了简单修订，摘录如下：

SQA感觉成天统计数据，没什么意义？

统计数据可以，对于SQA来说，要掌握数据分析方法，从数据中找出规律，得到结论，有明确的结论来影响大家。有数据，必须有结论，这样才能充分发挥数据的价值。

比如说：统计缺陷个数，测试人员一年发现多少BUG，测试人员一年的总工资多少，乘以2得到总成本，然后用测试总成本/总的缺陷个数，可以得到测试人员找到一个BUG的成本。

例子：无锡有个客户平均1636元成本找一个BUG，其他二三线城市也需要800-900元成本找一个BUG，一线城市如深圳的客户给的数据是1500多元找一个BUG。公布了这些数据，才能让大家意识到缺陷的成本有多高！而开发人员通过单元测试和代码走查，发现BUG的成本是通过测试发现BUG的成本的四分之一或五分之一，所以单元测试和代码走查非常重要，可以省很多成本。要通过小的浪费避免大的浪费，重视代码的在建质量，在生命周期的早期进行质量投入。

规模的度量可以采用功能点方法，有国际通用的计算方法，怎么样才算一个标准的功能点是有标准定义的。比如ISO 19761,即COSIC方法，我们在上海有客户就使用的很成功。

如果产品是偏底层，没有人机交互界面，更适合推哪些质量活动呢？

如果产品是偏底层，没有人机交互界面，更适合做代码走查，代码走查能更高效地发现缺陷。

代码走查的质量如何保证呢？

可以先推静态扫描，交给测试人员的时候，要同时来检查静态扫描结果，如果有些警告活error没有改完，则不进行测试，强制开发人员修改静态扫描发现的缺陷，养成良好的编码习惯。

我们目前的做法是：定一些质量指标，定目标，然后去看是否达标，未达标的会去分析原因和制定改进。

如果对某些指标做了考核，项目组可能会美化数据。

定目标是Y，但是没有找到影响目标达成的因子X，要找到X ，从根本上找到原因，解决问题。阶段性跟踪Y的达成，日程工作监督X的达成。有投入才有产出，要监督是否有真正的投入。

历史的包袱很重，不敢轻易去修改旧代码，新的代码修改也有可能触发出现问题，历史的代码功能也不能适应现在业务的需求，这块如何破？

历史的代码一般是能不动就不动了，不出问题不修改。当发生了需求变更或发现了错误时再去修改。

【分享实践：】杭州有一个客户，控制系统，短期内连续2次停电造成异常特殊情况故障，造成生产损失，从上到下都扣钱，10年前的软件，也是很冤。

这种问题要怎么破？

该背的锅就要背，有些缺陷是很难避免。

QA的价值体现，如何能让团队认可QA？

第一类QA：技术管理出身，能够真正发现团队的问题，问题指出就能得到团队认可，还能一起讨论解决方案，这类QA团队会主动来找你。

第二类QA：没有专业背景，缺乏具体的技术经验与管理经验，怎么办？

通过数据来说话，没有专业背景，就使劲研究定量统计的办法和分析，六西格玛方法，通过数据发现项目组忽略的问题。
不懂技术，我们懂方法，比如评审也是有方法的，我们可以去旁观项目组的同行评审，发现他们的过程问题，如：是否评审人都有发表意见，发现的问题都是哪些类的，会前找到的BUG是否是会上发现问题数量的4-5倍，一共50页设计文档，2小时评审，1小时评审了25页，怎么可能发现很多问题呢？再如复盘也有很多方法，有套路，比如头脑风暴、海星法、情感曲线、无管理者会议等等……
【分享实践：】无锡某客户的项目，花了一天时间复盘，有100多个发现。杭州某客户1年多的项目，我主持了1天的复盘会议，案例都有写到博客里了，使用的就是系统复盘的方法

QA可以不如研发团队懂技术，不比深度但是我们可以和他们比广度，QA见过的项目多，通过学习或看别的团队的优秀实践，教团队解决问题的办法，不懂技术，可以掌握发现问题的方法，不限于数据分析方法。要如何学习方法论？看书，培训，然后练习。
研发人员水平比较高的话，SQA可以促进跨团队之间的交流，建立起学习型组织，让大家互相学习别人的优秀实践。
项目多，可以设计一些度量指标，大家可以对比（横向比，纵向比），团队自己就很使劲，不用QA用太多力。
比如：项目健康指数，包括：效率，质量，成本等。

故障追责和根因如何处理引导比较合适？

定了制度和规范，如果没有遵守就要被追责，低级错误，不能原谅！

比较有深度的问题，超出能力范畴的，追责扣钱都没用，对解决问题没有帮助，需要团队自行反思总结。

公司管理平台很多，关于平台的建议：

统一平台，自己开发，公司到现在这种规模，就得自己投入开发一个统一的平台，类似于阿里、华为、百度自己内部的云平台。

  

测试和开发的人员比例？

很多公司都没有测试人员岗位了，都是测试开发人员，要写测试自动化程序，手工测试已经很少了。

测试人员测试的目的不是为了找BUG，而是为了证明达到上线标准，可以上线。

开发人员一定要做测试驱动开发，这样才能减少后期的测试投入，加快测试周期。

【分享实践：】某些公司，产品一立项，并行立项，一个产品项目，一个测试项目，产品项目完成，测试项目也完成，可以直接对接测试了

这么大的公司，这么复杂的环境，质量规划如何做呢？

自己脑袋里要有想法，然后去做对比，公司大的问题，本质问题在什么地方？

可以出去学习，学习行业内最佳实践。

建立质量体系最简单的是可以参考一个现成的标准、框架或模型，这是标准、框架或模型考虑比我们更完备，然后去裁剪、本地化，去解决本公司的问题。

任老师简单谈谈敏捷：

阿里，百度等这些互联网公司相对做得比较好，在工具上投入比较大，管理实践和技术实践都能通过平台来固化。

敏捷是高手玩的游戏，尤其是SM要有管理经验。要求SM根据工程经验，根据项目的特征定出很好的管理方案，大家达成一致的理解。团队的成员也要比较有技术经验。PO要全身心投入到项目组中。

建议敏捷的导入路径：先看板方法（通过看板先暴露问题，可视化）--再敏捷的技术实践—最后敏捷的管理实践，或者技术与管理实践同步搞，但是一定要导入技术实践！导入了管理实践是形似，导入了敏捷的技术实践才是神似！

项目组成员要了解敏捷背后的原理，为什么这么简单，为什么要这么做，不然很多敏捷实践就无法真正做到位，不能坚持下来。

要解决项目组的实际问题，不能仅仅依赖一种敏捷方法，要多种敏捷方法集成在一起。我们要思考，当多种方法集成起来之后，是否违背了敏捷的原则与价值观，是否还是敏捷？

【敏捷咨询实践分享：】

1.先给领导洗脑，什么是正确的敏捷，什么是错误的敏捷。

2.要求团队知道为什么要这么做。

上海某客户做了9个月敏捷咨询，结果是：按期交付，客户满意度高，上线后BUG少，团队能够自组织。

敏捷和加班怎么理解？

加班是否在做有价值的事情？加班的效率是否高？这是要打一个问号的。

PO这个角色很重要！

要求PO要真正投入需求？沟通需求，定方向，定优先级，随时检查，随时纠偏。

【分享实践：】上午沟通需求，下午验收需求，上午挨个和研发沟通需求，下午挨个验收，验收通过才给测试测试，项目组中应该配一个专职的PO，这样做需求的分析可做到位。

例子：很多手机厂商很多都是BUG驱动开发，第一款手机开发是需求驱动，后面基本都是BUG驱动开发。
————————————————
版权声明：本文为CSDN博主「麦哲思科技任甲林」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/dylanren/article/details/102574365