3
Posted on Sunday, June 19, 2011 by 醉·醉·鱼 and labeled under

flymoth,原由 zhongxiao37 上載。

那群飞蛾扑火。就像爱情,有时候,知道自己会粉身碎骨,依旧扑火;更有时候,从一开始,就不知道这是一场没有结果的长跑。

0
Posted on Tuesday, June 07, 2011 by 醉·醉·鱼 and labeled under

说burndown chart之前,还是有几个概念想先理一理。
  1. 其实,我不是QA,只是一个测试人员而已。
  2. 其实,严格来说,我的不是burndown chart,应该是burnup chart。
  3. 其实,我不是想装逼,但是,还是习惯了散装英语了。
公司在运行敏捷模式,其实有一个很有趣的图,就叫燃尽图(burndown chart)。在每个开发周期之前,dev/qa团队都需要对自己的任务进行预估。预估的时候,要考虑到风险的存在和自己团队的能力来预估。每天,每个人在下班之前都需要对自己任务记录时间,这样,就可以通过这个图表来判断你做了多少了,还需要多久能够完成。期间如果发现不够的地方,可以进行及时调整。到产品开发周期完成的时候,自己的任务应该是归零了的。

再看看自己的图吧!
我的确看见自己在log time了,如图中蓝色的线那样。但是作为QA,每个周期总有那么几天没有东西可测,于是你可能看见中途蓝色有一段时间是平的。总体来说,我在log time了。
再来看黄线,表示预估时间。开发周期已经开始了22天以后,QA才开始进行时间的预估。嗯,问题是,太迟了,PM那边完全不知道你到底能够做多少,进度怎么样。此外,自己的预估还不准确,此后还不停调整拨高,最后到达51个小时。(此后为回归测试时间,不考虑入内。)好吧,我总得来说,预估时间和实际时间比率为4:5(39:51)。
最后,再来看看绿线和红线。红线和黄线的起点是一样的。但是这次由于预估得太迟了,导致红线和X轴几乎持平。绿线表示自己还剩下的task有多少。一般,正常来说,红线为斜率为负数的线段,而绿线则围绕红线周围逐渐下降,直到最后归零。

这次,最失败的地方,就是黄线的预估和实际偏差太大了。
  1. 测试用例设计预估时间的时候,忘记了阅读需求时间的预估,此外还有邮件来回讨论等buffer的考虑。
  2. 测试用例执行预估时间的时候,忘记了对测试用例步骤复杂度的考虑。有些用例虽然只有一步,但是可能前面准备就需要很多个步骤,所以每个case花费的时间将近两倍,甚至三倍。此外,报bug的时间,和验证bug的时间,都没有考虑在这里面,仅仅考虑用例设计的时间。