测试需要技术和管理的综合分析
上一篇 /
下一篇 2009-12-15 20:55:55
/ 个人分类:测试管理
很凑巧,刚刚看到友人的BLOG,加上下午重温了下德鲁克先生的《卓有成效的管理著》,感触颇深。将事情做对,做对的事情都离不开分析。做最好的决策需要我们在技术和管理上都有足够的知识。
6月份公司抓PROCESS,对于已有的流程重新定义和规范化执行。在我们小TEAM中,我将此事压了下来,在没有对比标准的前提下,无法断定好的PROCESS一定适合Team。我花了整整一个月的时间收集了关于项目中的一些数据趋势,包括每日BUG数量,重要(severity>3)的BUG数,Reopen的BUG数,New的BUG数,FIXED的BUG数,客户Complain的时间和次数,测试人员的工作日志中空闲时间的分布,按项目模块不同,以项目Build version的时间为横轴,数量为纵轴简单的制成了四张图表。很明显的在每个Build version的发布随之而来的是BUG数,NEW的BUG数会增加,之后2天左右Reopen的BUG数和FIXED的BUG数会相应的增加,但随之而来的就是客户的Complain的次数增加。每周的最后一天测试人员的空闲时间会占40%左右,而重要的BUG数基本分布在NEW和Reopen的BUG中对半分。因此我们TEAM初步分析,由于周中压力大,对客户提出的BUG多以旧BUG为主,加上测试人员EMAIL中的语句委婉性有的不够。周末而是因为客户和我们时间差的原因,大部分都想周末了,呵呵。所以我的小TEAM实行了一些新的过程,讲BUG的VERIFICATION提到周一完成,对客户的EMAIL严禁出现祈使句吗,全部使用礼貌的疑问形式。周五的空闲时间,我安排对性能测试,WEB自动化测试的training。在之后的1个月中,客户Complain的次数降低,时间大多集中在版本末期(一般的趋势)。但NEW BUG的数量下降了14%,重要BUG数基本保持不变,但在第二周出现了BUG的Reopen率上升12%的事件(原来是传说中的美国国庆放假)。。。。看来老美的开发也是有趋势和假期波动性的。由于自己也参与了自动化测试的代码实现,所以对TEAM的开发率规律也做了一定的数据统计,在后期的代码refactor占40%的时间。所以只要抓住开发TEAM的规律,测试TEAM才能发挥最大的作用,学到最多的东西,实现双赢。这里都是做对的事情的实例。如何将事情做对,这里提供的只是意见,多看多学,在做分析的同时,还有测试的工作,只有知识才能帮你做最好的决策。每个月给自己的200书费都没白用啊,呵呵。好好努力啊,测试是一门艺术啊。共勉。
相关阅读:
- 自动化软件测试度量标准 (fishy, 2009-12-04)
- 分清功能重点,提高测试效率 (fishy, 2009-12-04)
- SMART原则-谈测试的目标管理 (tillere007, 2009-12-06)
- 项目中期实施自动化的效果评估 (fishy, 2009-12-07)
- 初感测试计划 (fishy, 2009-12-07)
- 敏捷是另一颗银弹吗? (fishy, 2009-12-08)
- 测试计划的制定 (fishy, 2009-12-08)
- 对测试过程进行可见的有效管理 (fishy, 2009-12-09)
- 影响软件测试有效执行的因素 (fishy, 2009-12-11)
- 项目测试风险总结 (fishy, 2009-12-14)
收藏
举报
TAG:
SQA
测试管理
测试进阶分析