3

飞蛾扑火

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

flymoth，原由 zhongxiao37 上載。

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

0

一个QA的burndown chart

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的时间，都没有考虑在这里面，仅仅考虑用例设计的时间。