如何用量化数据来激励测试工程师?
来源:互联网 发布:网络互助平台骗局揭秘 编辑:程序博客网 时间:2024/04/29 07:40
从度量角度看,量化数据适合团队绩效的考核,而不宜用于个人绩效的考核。但是,有时为了实行一些测试改进方法、实施某些有效的策略,需要设定游戏规则,通过这些规则进行奖励,以促进新的方法、策略的改进。这种奖励,看作是游戏(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合并为一个系数。
欢迎大家献计献策!
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=876374
- 如何用量化数据来激励测试工程师?
- 如何用量化数据来激励测试工程师?
- 如何用量化数据来激励测试工程师?
- 如何用QUnit来测试JavaScript代码
- 如何用QUnit来测试JavaScript代码
- 如何用QUnit来测试JavaScript代码
- 如何用QUnit来测试JavaScript代码
- 如何用Curl 来post xml 数据
- 如何用Curl 来post xml 数据
- 如何用 Robotframework 来编写优秀的测试用例
- linux如何用curl 来post xml 数据
- TestNG如何用excel来做数据驱动
- 如何用JSON数据来表示“张三的颜值很高”?
- 如何用八进制和十六进制来表示整形数据
- 如何用数据来做渠道效果的分析
- 【笔记】如何用共享单车数据来做城市规划
- 量化投资与数据分析一: 如何用PYTHON下载WIND数据并转化成dataframe格式 分享
- 如何用IM来营销?
- 质量的定义总会带有政治的和情感的色彩吗?
- 软件外包带来的利弊
- 微软的软件测试方法
- 软件测试架构师——众里寻她千百度
- 如何解释世界杯的众多之谜?
- 如何用量化数据来激励测试工程师?
- 测试用例的有效维护
- 看足球学习管理团队
- “五星”球队的巴西为什么失败了?
- 强大的Web开源测试工具—Selenium
- 每日培训
- 王志东祭起IM2.0大旗
- 合理的软件过程是软件质量的基础-论CMM/CMMI的缺点
- CMM和CMMI过程域的比较分析