我的软件测试之旅:(9)行动——简化测试文档和流程
上一篇 / 下一篇 2012-08-08 09:51:39 / 个人分类:杂谈
B-\YUH ne(Cr!n0 现有的各种测试相 关文档都很齐备,但是已经有较丰富经验的我感觉到其中的信息有很多都是不必要的冗余,老早就想把它们给简化简化。因为我这个人总觉得,如果是没有必要的或 者不需要的信息,为何一定要放在文档里呢,直接不写不就行了么?放在那里总会吸引人去看一眼,然后心想“哦,N/A。”,这也是时间和精力的浪费啊!保持 文档干净整洁,只记录有意义的信息,不是很好么。而且,在原来的测试管理工具中,测试用例和测试计划,都有很多不同的版本,针对的是不同的产品发布版本。版本多也好的,但问题就是有的时候时间上最新的版本不一定是信息最新的,对于后续的测试人员来说,这会增加他们的工作量。还有就是每一份测试计划所描述的都有局限,所有的信息都是针对当时的那个版本测试任务,针对其中所要验证的功能,而这只是被测对象所有功能的一个子集,看不到一个整体的景象。51Testing软件测试网\qb*\'r v_g*qa]
51Testing软件测试网.iQF8UT7ZXW$y'tScrum试点项目提供了这样的一个机会,可以去操作这种简化,因为我是第一个,也是项目团队数量扩张前的唯一一个测试出身的团队成员,一定程度上享有 一锤定音的权力。而Scrum这种开发模式,要求测试用例的全集必须能持续地体现被测系统的全景,因为每一个迭代所新开发出来的功能都要进行验证,而之前 已经存在的功能也需要进行回归测试(其实在敏捷的 方式下,“回归”这个说法已经没有了意义),因此我们必须随时都掌握着当前最新的测试用例集合。而另一方面,增量式的开发需要频繁地回归验证以前的功能, 对手工测试的方式来说这是不可能完成的任务,必须秉持100%自动化的思想,而这也正是我的坚持。不过当时我和Scrum Master以及项目经理在100%自动化上的意见有些出入,为此交流过无数次,我记得最后我们还是坚持了100%自动化的想法,因为我确确实实就做到 了。
5OCaT6Rgz051Testing软件测试网/FH6?ycH自动化的地位得到提升,间接地使得另一个问题浮出水面,也即测试计划。在传统的模式中,由于测试工作大多根据模块或者领域来划分, 以单个项目的形式来进行管理,持续时间较长, 每一个测试项目所要验证的功能数目也比较多,因而需要安排一个单独的测试计划环节,还需要产生出测试计划文档,并且由相关人士来评审。但是在Scrum这 种迭代增量式开发方式下,每一个迭代所开发的功能数量都不会很多,而要执行的测试用例却呈现不断增加的趋势,因为它要执行新功能测试用 例加旧功能回归测试用例。对于测试计划这个活动来说,如果每一个迭代都要开测试计划评审会议,产生测试计划文档并且得到批复的话,将会是一笔非常大的管理 性开销,而且每一个测试计划的重复信息量都很大,还会产生很多的版本。因而测试计划这个活动在Scrum模式下必须得改变才行。51Testing软件测试网~7mE:K QK7}!fU
51Testing软件测试网nU;~~b}Cp还有一 个收到影响的就是缺陷追踪实践。我们也就是4个人的团队,而且都坐在同一个会议室里,面对面肩并肩。如果发现一个缺陷,还得打开IE浏览器(呃,其实我用 FireFox更多一点),打开缺陷追踪系统的网页,输入各种信息提交缺陷报告,等待邻座的开发人员在专心写代码的时候收到通知邮件,打开网页,研究分析 缺陷相关的信息,然后再给我提要求,然后我们再通过网页来回几个回合?当然这样做很没有必要,我们自然是可以面对面交流的,但是交流完解决了问题,我们是 否还需要记录呢?将这样的问题记录到缺陷追踪系统中去,到底有没有意义,毕竟记录信息也还是要花时间的,而这样的问题可能在一个迭代里会遇到很多,还有可 能很多缺陷并不是什么大问题,几分钟可能就改好了,要记录吗?