测试需要技术和管理的综合分析

上一篇 / 下一篇  2009-12-15 20:55:55 / 个人分类:测试管理

很凑巧,刚刚看到友人的BLOG,加上下午重温了下德鲁克先生的《卓有成效的管理著》,感触颇深。将事情做对,做对的事情都离不开分析。做最好的决策需要我们在技术和管理上都有足够的知识。

6月份公司抓PROCESS,对于已有的流程重新定义和规范化执行。在我们小TEAM中,我将此事压了下来,在没有对比标准的前提下,无法断定好的PROCESS一定适合Team。我花了整整一个月的时间收集了关于项目中的一些数据趋势,包括每日BUG数量,重要(severity>3)的BUG数,ReopenBUG数,NewBUG数,FIXEDBUG数,客户Complain的时间和次数,测试人员的工作日志中空闲时间的分布,按项目模块不同,以项目Build version的时间为横轴,数量为纵轴简单的制成了四张图表。很明显的在每个Build version的发布随之而来的是BUG数,NEWBUG数会增加,之后2天左右ReopenBUG数和FIXEDBUG数会相应的增加,但随之而来的就是客户的Complain的次数增加。每周的最后一天测试人员的空闲时间会占40%左右,而重要的BUG数基本分布在NEWReopenBUG中对半分。因此我们TEAM初步分析,由于周中压力大,对客户提出的BUG多以旧BUG为主,加上测试人员EMAIL中的语句委婉性有的不够。周末而是因为客户和我们时间差的原因,大部分都想周末了,呵呵。所以我的小TEAM实行了一些新的过程,讲BUGVERIFICATION提到周一完成,对客户的EMAIL严禁出现祈使句吗,全部使用礼貌的疑问形式。周五的空闲时间,我安排对性能测试WEB自动化测试training。在之后的1个月中,客户Complain的次数降低,时间大多集中在版本末期(一般的趋势)。但NEW BUG的数量下降了14%,重要BUG数基本保持不变,但在第二周出现了BUGReopen率上升12%的事件(原来是传说中的美国国庆放假)。。。。看来老美的开发也是有趋势和假期波动性的。由于自己也参与了自动化测试的代码实现,所以对TEAM的开发率规律也做了一定的数据统计,在后期的代码refactor40%的时间。所以只要抓住开发TEAM的规律,测试TEAM才能发挥最大的作用,学到最多的东西,实现双赢。这里都是做对的事情的实例。如何将事情做对,这里提供的只是意见,多看多学,在做分析的同时,还有测试的工作,只有知识才能帮你做最好的决策。每个月给自己的200书费都没白用啊,呵呵。好好努力啊,测试是一门艺术啊。共勉。


TAG: SQA 测试管理 测试进阶分析

 

评分:0

我来说两句

日历

« 2024-03-11  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 147369
  • 日志数: 22
  • 建立时间: 2009-10-14
  • 更新时间: 2010-07-27

RSS订阅

Open Toolbar