如何用量化数据来激励测试工程师？.docxVIP

如何用量化数据来激励测试工程师？ 由于软件测试工作需要每个成员都需要有高度的责任感、全身心投入，我们就必须通过良好的管理方法和一系列激励措施，使测试团队保持高昂的士气和高度的责任感。在我写的《软件测试方法和技术》第12章介绍了许多有效的方法，在这里主要想详细讨论具体的量化方法。 从度量角度看，量化数据适合团队绩效的考核，而不宜用于个人绩效的考核。但是，有时为了实行一些测试改进方法、实施某些有效的策略，需要设定游戏规则，通过这些规则进行奖励，以促进新的方法、策略的改进。这种奖励，看作是游戏(game)的、临时的奖励，而不是做年终的绩效考核。 对于测试，最容易进行量化的有两个数据：测试用例(test case)和所发现的缺陷(Bug)。test case的数量、覆盖程度（功能覆盖率、缺陷覆盖率）等是比较容易量化的，而Bug的度量数据更多x些，如所发现的bug数量、描述不清楚的Bug数量、不是Bug的Bug数量、遗漏的Bug数量（被客户发现——Remedy Tickets、或在下一个版本发现——Late Discovery Bug）等。对于Bug度量的数据，最重要的两项是所发现的bug数量和遗漏的Bug数量，前者是测试效率和设计/代码的 质量度量，后者是测试质量（也包括设计、代码质量，我们坚信质量不是测出来的，而是构建出来的）的度量。遗漏的Bug数量对质量度量的更有效些，但是不能及时获得，必须在产品发布之后才能获得。所以，为了实现测试的效率，有时必须靠“所发现的bug数量”来度量。为了更客观度量，考虑到bug的严重性、技术难度、产品类型、模块稳定性等因素影响，不是用“所发现的bug数量”，而是用“所获得的bug value (缺陷值)”来度量，公式被定义为： Bug_value = （P0_Bug_Number × 1.6 + P1_Bug_Number× 1.4 + P2_Bug_Number× 0.7 + P3_Bug_Number×0.3）× Wd × Ws × Wt 其中：P0_Bug_Number：致命的（fatal）缺陷数量 P1_Bug_Number：严重的（critical）缺陷数量 P2_Bug_Number：一般的（major/normal）缺陷数量 P3_Bug_Number：次要的（minor）缺陷数量 Wd: 技术难度系数，如Database, Enterprise Server, Java难度系数大，发现Bug不容易，Wd可以定在1.5 – 5.0 Ws: 稳定性系数，全新模块，Bug比较多，发现缺陷比较容易；版本越高，越稳定。Ws可以定在0.5 – 1.0， 假如以version 10.0为1.0, Version 1.0 = 1/100, Version 2.0 = 4/10, Version 2.0 = 9/100, …, , Version 8.0 = 64/100, Version 8.0 = 81/100 Wt: 产品类型系数，可根据实际情况和历史数据来判断。Wt也可以和Wd合并为一个系数。 本文来自CSDN博客，转载请标明出处：/KerryZhu/archive/2006/07/04/876374.aspx 测试管理之绩效考核 编写背景： 工作所在的部门启用了新的绩效考核制度，也开始了我参与对测试人员的工作进行绩效考核这一管理活动，第一次的考核结果让我有很多的感想，因此今天把它记录下来，也许突然有一天回头看这一感想，又会是另外一份心情。 思考：给测试人员进行绩效考核的目的是什么？ 经过思考，我总结的答案是： 1、? 为了了解工作情况，如：工作进度、工作状态。 2、? 对每个人的工作进行评比，夸奖好的，批评差的。这个看起来有点像在学校上学时候的考试。 思考：有了这样的绩效考核目的，要用什么样的方式、方法去实现呢？ 怎么样的绩效考核方式是最有效的呢？ 对于现在的我，在现在这个小公司要想做好这个绩效考核，真是要好好思考。 1、? 不同的工种，不能用同一种考核方式。如：测试人员的考核方式就不能和开发人员的考核方式相同。 2、? 不同工种的考核结果是没有可比性的。如：测试人员的考核结果和开发人员的考核结果进行对比是没有意义的。 以上这两点不知道我的领导是否认同，还需要等到下一次考核的时候和他沟通沟通。 这是工作以来，第一次站在一个管理角色去思考、去做绩效考核这个工作。这第一次的考核工作让我不知道用什么语言来描述我的感受。 考核的结果是：测试组整体的分数都比开发的低，从排名和等级划分上可以说是包尾了。从分数上看，我的第一感觉是：难受。第二感觉是：生气。在和领导进行一系列沟通后，在回家的路上一直在思考、分析着这个结果，问题出在那里呢？问题出在那里呢？？？？