质量的分级

标签：不可   紧急   分析法   一个   bug   覆盖率   测试   需要   定位   

我想表达的质量的分级，并不是质量分级管理策略，而且在面对不同规模的质量团队的时候，跟踪质量采取的策略不一样。

1. 作为部门体系建设者，40-100人规模，迭代中的产品很多的情况下

• 质量数据，质量数据分为几个方面，一个是prod bug，一个是prod bug逃逸率，比较分为，横向比较和纵向比较，横向是不同的时间段，自己和自己比；纵向，是同一个时间段，部门内部产品对比。比较的意义在于，形成探讨和争议的氛围，从而激起大家的质量意识。并通过此，制定合理的质量目标。付出行动。我觉得我的团队在此上做的并不好，质量数据放在那里就在那里了，没有起到应有的效果。落实还是需要高层支持的
• prod bug纳入问题管理，如果想以点带线带面，将问题分清楚，那么需要prod bug的5why分析法，分析到组织架构和质量体系优化层面
• 关注成本和效率。时间和人员都是企业的资源，缩短质量反馈时间，控制人员成本，如何去做，需要全局评估
• 注意：不可以一个指标去评价某个产品的质量，需要多个质量数据协助分析

　　2.  一系列有关联性的产品的质量负责人（10-20人）

• 有些质量，是可以通过质量数据的综合分析进行获取，有些是通过质量数据察觉不到的。比如，开发人员未按照架构设计去实现产品，因为产品需求的紧急性，在存储数据方面，尤其在跨系统集成上，就近存储从而避免和其他团队的沟通；又比如前后端设计上， 业务逻辑放在前端做处理。这些是JIRA，或则bug中无法察觉的点，需要深入技术细节才能发现。这就需要质量负责人敏锐的嗅觉，产品意识，架构思维同时又能深入一线
• 问题定位，同问题管理，一个生产事故和prod bug往往都是质量体系不完善的很好的切入点。我当前发现的质量问题，很多根本原因都是组织架构不合理导致，比如，产品人员，来自不同的部分，彼此产品有紧密关联的情况下，大家会从自己最方便的角度考虑，而缺乏全盘的产品架构的设计；比如，同一类型的产品，技术架构分属于不同的团队，技术缺乏统筹此类的问题

　　3. 一线测试人员

• 测试覆盖率
• 有无合理的测试策略进行全部覆盖并且能快速给出反馈
• 能否基于真正用户的角度去考虑，测试用户产品。这点很多测试人员十分缺失，我们更多追求测试的花样性，而缺乏对于产品价值的认真思考。我们有出现过为了追求新技术的应用，影响用户基础功能的情况

质量的分级

标签：不可   紧急   分析法   一个   bug   覆盖率   测试   需要   定位   

原文地址：https://www.cnblogs.com/ilazysoft/p/13399234.html