测试小组的负责人如何统计和收集数据？（09-12-21）（获奖名单已公布）

默默巫

作为测试小组的负责人，如何统计和收集数据，让领导感觉到测试组做了不少工作呢？

快年底发奖金了，一直为工作总结而发愁。作为软件测试的负责人，如何去统计和收集数据，让领导感觉到测试组做了不少工作呢？怎样去统计？需要统计那些数据和指标？

此话题由会员sstic提供，如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	shaofei19820625	当当购物卡50元	12#
二等奖	jscn1982	300论坛积分	3#

sunpeng

那就写的玄乎写  写的越玄，领导越高兴

jscn1982

个人觉得两个方面：
一是测试组实实在在到底做了什么工作： 这方面包括编写了多少测试用例、测试了多少个版本、执行了多少用例、团队建设怎么样(团队技术实力提升情况、积累的产品知识、积累的技术文档情况)等
二是测试组给公司带来的价值，主要就是发现了多少Bug，给公司节约了多少成本(这里不一定实实在在算节约了多少钱)。但是这过程中一定要强调发现了多少严重Bug，这些bug如果存在会产生什么样的严重后果等。当然还可以包括需求阶段发现了多少问题，设计阶段发现了多少问题，节约了时间成本。

msnshow

其实测试部门算是一个后线的部门，要说成绩，就是经过测试上线后的系统没有出现什么问题，用户很满意

然后就是团队建设、技术实力的提升之类的了

[ 本帖最后由 msnshow 于 2009-12-21 21:25 编辑 ]

UU1983

这种数据时天长日久积累下来的怎么到了年底一拍脑袋才写呢？

作为测试组的负责人，在年之初始你就应该做好工作日程表和成绩考核表
一方面对年终总结大有益处另一方面可以考核测试人员的技术程度、进步程度、技术缺陷和职业素养
无论写什么都要在实事求是的基础上，既不夸大也不妄自菲薄，测试组是部门中最闲不住的人了，如果一年了你们发现什么都没干，我只能说一你们公司要倒闭了。二你这个负责人不合格没有做好工作记录
下面我说说在有工作记录的前提下如何写好工作回报总结
工作数据从哪几个方面下手收集
一总结项目
一年之中总会有几个项目做吧，把他们的名称写出来
二进入项目记事录
查看这个项目都做了什么工作，遇到了什么困难，在这种困难的前提下，大家克服了困难，快速的解决了问题为公司做出了哪些贡献如争取时间得到良好的客户评价，致使回款快速等
如果你什么困难都没遇到那我只能说你们都是精英啊。。。。。。其实任何项目都有很难解决的难题。

三将前两条进行分工合并
数据就出来了
对于每个人的数据搜取还是要依靠以前是数据，评价一定不能有失公允，要公正、公平、公开
赢要漂亮输要服气
千万别夹杂个人感情不如以后的队伍就不好带了
顺便一句这东西如果你要把一个人写的太糟除非你想不要他了，否则还是不要那样写的好。什么事情家里说清楚，不要当着领导说，否则领导不会认为他有什么问题，而是你领导能力有问题没管理好团队。
哈哈经验之谈，如果你想开人可以写报告里

wzxshi

感觉5楼说的不错，顶了

snllll

那要看什么样的公司了，如果公司领导是技术出身，要是搞的太邪乎不太好，还不如抓住重点，写发现的重大bug，最后总结下给开发团队各个层面生产力的提高。搞的太虚不好！

假如领导好大喜功，发奖金的事由他拍板说话，那么一定要讲究阅读的质量，总结要写的漂亮好看！

哈哈

snllll

5楼说的非常好！

woodcraft

说说我的“临时抱佛脚”的办法吧！毕竟不管怎么样，涉及到领导以后的重视程度与明年的资源分配呢！

数据的来源：
1、自己从相关测试文档中收集。
这里指的文档主要是测试流程中要求的一些文档，从这里找数据。

2、各项目负责人提供。
平台太多，业务太多，可让相关测试项目负责人一同帮你找，而不是你一个人找。

3、从上下游着手收集的数据。
软件开发人员的数据，如果他们整理好了，可以拿来参考使用。软件测试完了需要发布，可同软件接收人员沟通，让他们提供一下今年发布了多少软件。

数据的要求：
1、BUG数
这个数据是一定要的，体现工作成果的。来源可通过BUG管理平台（基本上大家都有用吧），从里面直接获取今年提交的BUG数量。

2、项目数
这是体现工作量的。自己如果统计不出，可通过软件开发人员（基本上他们有工作量，测试就跑不了），或者从发布软件的数量统计。

3、测试轮数与执行用例数
这也是体现工作量的，一般来说，项目数都不会超过100，领导对此没概念，也不会“震撼”.......
轮数就多了.....什么，没记录？OK，那找找软件人员的版本记录吧.....没有？那我也没办法了.......
执行用例数，如果你能统计出来，估计那是相当震撼的一个数字，不过基本上比较难.....

4、其他数据
恩，这是体现工作成果的，比如说系统上线后的用户投诉等等，找支持部门或品管部门要下吧，如果不太好，那就别说了，反正他们部门总结时会说的..........


话说回来，同意5楼，明年还是注意平时收集吧！取巧的感觉真不好...........

UU1983

多谢大家的赏识，谢谢

于于于

1 测试计划统计
2 测试用例统计
3 测试缺陷统计
4 测试报告统计
如果还有后期的文档工作，也要进行统计。

shaofei19820625

从楼主的问题里分析，楼主做这个年度总结应该是对测试负责人的考核，而不是对小组里其他成员的考核吧。
那我觉得要从领导想了解什么信息去入手。领导关注的不是你的过程，他要的就是结果。而要让他了解你带队的小组做了很多事情，那么必须将你的产出量化给领导看。我觉得有以下几个方面：
一、项目。作为负责人，你可以制定一个表格，让各个项目负责人去填写统计。表格包含以下方面
1、项目名称
2、项目规模。分项目开发人数、项目测试人数、项目周期、项目测试用例数等几方面去统计
3、项目线下bug数
4、项目线上bug数
5、项目是否有严重bug：每个公司对严重bug的判断标准不一样，根据你自己的公司情况来
6、产出：《缺陷分析报告》、《项目测试总结报告》、《业务总结报告》等等，附件最好带上，或者告之共享目录地址。我认为这部分很关键，项目结束之后的一系列总结就是你们组的沉淀，要说明清楚这些总结给别人带去了什么价值。比如项目测试总结会将你们项目过程中的一些好方法啊，好的教训啊总结出来和大家分享。
二、团队建设。
做为小组负责人，不光光关注的是你小组里各项目的情况，还需要关注小组成员，就是对人的管理。因此为了这个团队的发展，你做过什么事情,产出了什么。
1、新人：人数，师傅，业务学习方法，业务能力考核方法
2、小组成员的技术能力的学习和提高氛围
3、组织了几次内部培训，效果如何
4、和其他小组间有没有进行过学习交流
5、小组所负责的业务知识沉淀
6、小组里的一些规范的建立
...............

总之，同楼上说的，以上所有的内容要统计出来，还是靠的平时的记录，所以作为测试负责人其实还需要培养团队的这种习惯。还有，要做出这些统计，靠你一个人的力量也是不行的，还需要团队成员的积极配合。

[ 本帖最后由 shaofei19820625 于 2009-12-23 14:01 编辑 ]

mars_diablo

楼上各位大大已经说的差不多鸟，我觉得综合一下就好
个人感觉写总结还是要看所处环境，领导是怎么样的，技术型，管理型，还是浆糊型...再看边上的开发组，他们都是牛人啊，小心你的年终总结里得罪了他们可是让来年不好过的，要是写得你好我也好，说不定他们来年美言几句，领导就批准你申请的各种设备...再看手下的兄弟们，如果他们和你出生入死，为你扛枪档炮你写差了怎么对得起他们，如果他们成天大事不做，只游戏聊天，那你写好了就是在给自己埋炸弹
SO，领导是技术型的，一定要多谈自己的小组是如何克服了技术上的难题解决了XXX问题，最终取得了XXX成绩。还有一个重点就是在这一年里小组又学习到了什么，这个是技术型领导喜欢看到的。管理型的领导注重数据，在数据上一定要多下功夫，平日的收集很重要，最好不要打马虎眼，糊弄了的话被揭穿是很尴尬的事情，可能就从此打入冷宫了。浆糊型的就要把马屁功夫发挥到极致，领导是如何的好啊，如何的英明之流啦....
还有就是无论哪种领导，其实都是很忙的，所以对总结的东西还是有一定的要求，最好能即说明问题又简洁，不要曲折离奇，这样他们是么心想看下去的...
如果有取巧的话，也是对付浆糊领导，但这类领导是最考验写作水平的，如果写作水平不佳，很可能马屁拍到马腿上....慎之...

zhanghl

对测试团队测试设计能力的体现，对测试用例的数量进行统计，对测试用例的广度，深度，有效性进行统计。
对测试团队测试执行水平的体现，对测试执行中的测试执行效率和执行质量进行统计，如遗留的缺陷百分比，每个人日所执行的测试用例数，每个人日所发现的缺陷数，每修改KLOC所运行的测试用例数。
对测试团队管理水平的体现，对测试计划的执行情况进行统计，计划与实际工作的符合程度，测试成本控制，测试风险控制等。

Yr-Test

写出的东西一定要量化，最好能做出报表，邻导一般都没啥子时间仔细去看，所以最好有具体的数据，一看就能一目了然。
我以前为了向邻导申请编制人员，就写过类似的统计报表。

majun915

我虽然不是测试人员 但是还是学习了 呵呵    都说的很不错

夜魅

支持5楼

UU1983

谢谢大家的支持

龙雨

一定要突出成本！这是最体现测试团队存在价值的地方。

UU1983

成本固然重要，但是质量是更重要的，如果就招一个人，出去的东西总有问题，算算这中成本要比多招几个人多好多