软件测试之质量的管理

软件测试之质量的管理

核心的思路是对缺陷做分析和考核，并做研发流程中主要问题的梳理和改善。

常常做的事情可以从下面几个方面来看(这里会是主管以上的人来负责)：

1. 做质量数据的统计和分析

收集的数据很多，常见的有：

- 外网的bug情况，包括事故，及影响的程度

- bug的横向跨团队和系统的对比，纵向的和历史情况对比

- 版本发布的情况，代码变更行数的情况

从这些数据的收集中就能发现很多问题，比如问题集中在哪里，哪些模块，哪些人，哪些类别等等，以及有没有改善。

2. 问题的追溯和对于开发的考核

这个方面也许有一些争议，但是我还是觉得这个是一个很重要的方法。光靠观念和自觉是不够的，必需要有一定的反馈机制，就好比交规一定是配合着扣分和罚款等手段，否则记录闯红灯有什么意义呢?而且现实的来说，这些方法起到约束的作用，也是一种心理暗示，要做自己做的东西负责，也便于养成好的习惯。

通常的考核指标涉及这些方面：

- 编译失败次数的考核

- 外网事故和bug的数量

- 测试阶段的bug，特别是基础功能bug和严重bug

粗略的列了这么多，其实可以有很多，比如配置文件改错的情况，漏提测文件的次数等等。

对于bug方面其实也是一样，如果开发在乎(或者被迫在乎)外网bug或者被测试发现的bug数量，他写代码的时候一定会更仔细，也会做些简单的自测，让提测的质量更高，提高了整个研发系统的效率，同时也是提升了质量，因为quality must be built in。

我个人的经验，作为测试人员几乎同时面对过两个开发团队，一个有上述的考核，一个没有。表现出来的版本质量和对质量的关注完全不一样，而且前者也并没有出现开发和测试的对立，以及测试不敢提bug等负面的情况。

3. 对于测试的考核

除了对于开发的考核，同样也有对于测试的考核，这样也更加的公平。

测试的考核通常考虑下面的指标：

- 漏测：绝对数量或者漏测率

- 版本的工作量和测试效率

- 发布延期的情况

如果测试有这样的压力，也需要不断努力去发现更多的bug。

说起考核，总有人觉得这不符合智力劳动的情况，或者互联网的作风，其实不太理解为什么会这么觉得，放眼望去，有什么工作不被考核呢，sales要背quota，为什么软件开发和测试不能对自己的工作的质量负责呢?当然，具体的指标如何去定才更合理那是另一个要去考虑的。

换个角度来看，适当的压力(不应该导致焦虑和扭曲的做法)，其实是让一个人表现最好的状态。

4. 推动开发的自测

这个问题一向是个老大难问题。愿意自测的开发团队你不用太多的推动，不愿意做的推动也很难，或者你无法判断他有没有做自测。而且这方面，通常取决于开发负责人的观念和态度。

如果是介于之间的，我们可以做一些事情，比如：

- 统计测试阶段的bug中，属于开发可自测发现的比例。通过这个可以看有多少bug是不应该到测试阶段的，以及横行纵向的对比。当然这个标准要自己拿捏。

- 给出一个自测的checklist。开发在提交前要完成这个list并正式的给出报告。这个方式我们曾经在一个项目中用过，效果不错，基本功能都通过这个保证了，前提是开发负责人认可。

- 有一套自动化验收的用例，可以挂接到自动部署之后或者daily build。前提是我们的自动化要足够的问题，效果才会好。

这个阶段除了业务测试的努力，也体现出了QA的价值。这里的QA是指质量管理，有的地方叫SQA，专注在质量度量和研发流程的管理上。

到这个阶段，发现事情顺了很多，质量也有更大程度的提升，并有改善的趋势。