最近微信朋友圈看到任老师关于质量同仁总结的一些常见问题及见解，看完觉得受益匪浅，以下文章是借鉴任老师的文章谈谈自己的一些看法。

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

—————————————————————————————————————————

统计数据可以，对于SQA来说，要掌握数据分析方法，从数据中找出规律，得到结论，有明确的结论来影响大家。

有数据，必须有结论，这样才能充分发挥数据的价值。

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

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

规模的度量可以采用功能点方法，有国际通用的计算方法，比如ISO 19761。

—————————————————————————————————————————

个人见解

无数据不质量，质量人员就是要拿数据说话，不过在做数据统计及分析之前需明确数据统计的意义，目的在于展现哪个方面哪个层次的问题？数据好说明什么，数据差又说明了什么？横纵向对比又能找出哪些可借鉴可改进之处。

当然前提是源数据正确，统计方法可行。

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

—————————————————————————————————————————

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

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

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

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

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

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

—————————————————————————————————————————

个人见解：

可以在人工代码审查前利用相关工具如sonarqube完成静态代码规则扫描，对于致命或严重的问题需修改，也许当前不修改并无影响，但积沙成塔，问题总会再某一天爆发。

另外，对于人机交互的产品或系统，质量管理人员应熟悉系统操作，明确业务痛点及主要业务数据量及用户量，知己知彼才能更好的制定质量保证措施。

人工代码审查建议采用Gerrit、Gitlab merge request等工具实现，此外颗粒度最好控制在100-200行每次。因为根据经验，开发人员阅读代码的专注度会随时间下降，所以应控制代码评审的颗粒度

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

—————————————————————————————————————————

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

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

—————————————————————————————————————————

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

—————————————————————————————————————————

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

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

通过数据来说话，没有专业背景，就使劲研究定量统计的办法和分析，六西格玛方法，通过数据发现项目组忽略的问题。

不懂技术，我们懂方法，比如评审也是有方法的，我们可以去旁观项目组的同行评审，发现他们的过程问题，如：是否评审人都有发表意见，发现的问题都是哪些类的，会前找到的BUG是否是会上发现问题数量的4-5倍，一共50页设计文档，2小时评审，1小时评审了25页，怎么可能发现很多问题呢？再如复盘也有很多方法，有套路，比如头脑风暴、海星法、情感曲线、无管理者会议等等……

QA可以不如研发团队懂技术，不比深度但是我们可以和他们比广度，QA见过的项目多，通过学习或看别的团队的优秀实践，教团队解决问题的办法，不懂技术，可以掌握发现问题的方法，不限于数据分析方法。要如何学习方法论？看书，培训，然后练习。

研发人员水平比较高的话，SQA可以促进跨团队之间的交流，建立起学习型组织，让大家互相学习别人的优秀实践。

项目多，可以设计一些度量指标，大家可以对比（横向比，纵向比），团队自己就很使劲，不用QA用太多力。

比如：项目健康指数，包括：效率，质量，成本等。

—————————————————————————————————————————

个人见解：

了解团队需要什么，为达成质量有什么困惑，一起制定合理的计划，按计划推行并及时调整，记住，战线一定要统一

比如写文档这事

如果团队成员均是较资深人员，且对业务很熟悉，可以上手实现业务需求，文档指引的作用就弱化了，可将这部分时间投入其他环节，如果团队新人过多，反复沟通成本较高，需文档指引完整相关工作，那么高质量的文档编写及评审就是必须的了

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

—————————————————————————————————————————

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

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

—————————————————————————————————————————

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

—————————————————————————————————————————

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

—————————————————————————————————————————

个人见解：

或者尽量用一套工具，同类型多工具并行会带来很多额外的工作量

问题七：测试和开发的人员比例？

—————————————————————————————————————————

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

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

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

—————————————————————————————————————————

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

—————————————————————————————————————————

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

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

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

—————————————————————————————————————————

个人见解：

带着问题出发，了解目前的业务痛点，对比过往经历以及行业内的优秀实践，从点到面一步步推开

不用着急一步达成，胖子也不是一天天养成的，一个个点攻破，有了改进就有成就感，有了成就感就有继续的动力了

问题九：敏捷怎么推行：

—————————————————————————————————————————

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

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

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

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

【敏捷咨询实践分享：】

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

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

—————————————————————————————————————————

问题十：敏捷和加班怎么理解？

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

PO这个角色很重要！

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

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

—————————————————————————————————————————