QA 项目质量报告写作案例分析与总结

2018年3月22日

质量例会上，各个 QA 结合自己所写的项目质量报告，汇报所看护项目质量状态、风险和问题。就 QA 项目质量周／月报告写作本身质量做了一番点评和审视，存在一些不足，总结如下：

报告存在两大类问题：

1、亮灯与点评信息不一致，传递错误的信息，带偏管控焦点，是一种管理浪费

2、只描述数据表现，没有给出质量评估结论和观点，无法支撑管理决策

 

案例分析：

案例1：某项目亮为黄灯，意味有风险和问题预警，但是 QA 在项目点评中，却反馈质量良好，无问题。

分析点评：

1、综合亮灯，是自动生成。亮灯规则中各项量指标的目标值是一样的，即：并没有根据项适配。亮灯结果不对是报告表单工具局限性致，但是 QA 不能视而不见

2、 QA 在写报告的时候，要注意所专递信息准性，审视亮灯与事实是否相符，必要时手动调处理错误信息，灵活应对。

 

案例2：某项目综合亮灯为绿灯，但是过程质中却有描述出现低级问题、不达标等。

1、报告描述：方案评审缺陷密度过低，不达标。

分析点评：只是描述了数据表现，并没有陈述问题和评估结论。评审缺陷密度过低只是表象，并不一定反映真实问题，需要收集下游环节的开发和测试的评价，来评估方案质量到底如何，风险是否可控？

2、报告描述：开发过程中出现2起编译未通过的低级问题。

分析点评：描述没有上下文，未描述低级问题的影响、是否可控等。管理者看完后，无法定性问题的性质，拿不准问题严重与否，不知道该如何决策。

另外，针对此项目的低级问题，据我所知，虽然之前有加大处罚力度，但是仍旧是屡禁不止。可见，事后惩罚已经不具备影响力，

那么基于这样的现状，如何事前做到防呆？

 QA 不能跟着业务，只接收了这个现实而束手无策。而是要发挥鲶鱼效应，想办法激活项目组去思考改进，可以建议和推动成立专项改进组、研讨、定制度、定流程，优化工具等。

3、针对项目的亮点， QA 可以给予更多的观点和建议，推动亮点产生更多收益。比如：建议从应用价值和效果方面，规划输出优秀实践，Q2申报奖项。

 

案例3:只描述数据表现，没有给出质量评估结论和观点，无法支撑管理决策

1、报告描述：自验证、热部署使用率下降

分析点评：

到底是什么原因？执行力不足？还是项目组认为价值不大？还是工具不好用，还是其他什么原因？ QA 需要跟进原因分析，从 QA 角度给出合理有效的改进建议。

2、报告描述：过程质里中自验证、热部署使用率下降，且代码评审缺陷密度较低，代码质里存在潜在风险

分析点评：论证理由不充分，结论给得过于草率。建议组织代码交叉飞检，以第三方检查结果来审视代码质量到底如何。

 

总之，

1、研发过程中的度量数据只是表现，并不是事实和问题本质，它只是作为风险和问题识别的一个切入口。

2、通过异常数据这个突破口来跟项目组进一步深入沟通，多问几个 Why ，挖掘出项目真正存在的问题、困难、阻力和诉求，这个才是 QA 的出发点。

3、项目过程规范性管控是基于风险和问题的管控，并不是僵化的要求项目组干篇一律遵守规范执行，追求过程的完美。

4、软件研发过程并不像制造业生成流水线那样，分毫不能差。每个软件项目交付过程都有它自身的制约因素，所以应该结合项目自身的特殊性来定性和适配

5、 QA 并不只是僵化的硬推项目组落地公司要求。需要从第一性原理角度，去审视公司要求对于项目组的合理性和价值量，帮助项目组“有所为有所不为”（也就是所谓的裁剪、适配和备案）。我想，这才是项目组收欢迎的 QA 。

        一份 QA 报告，如果仅描述数据没有给出结论，则并不能讲清楚问题或风险所在，也无法给领导提供决策判断依据，那么这样的报告是耗无价值的。所以， QA 的报告中除了描述数据表现外，要结合了解到的事实，来做质量、问题、风险评估，给出结论；同时，针对问题和风险，从 QA 角度给出改进建议。

        有数据有结论有观点，我想，这样的报告才是业务线想看到的！