Tuesday, July 11, 2006

测试项目的方法论

May 03, 2004

最近我在客户的一次门户概念原型测试中完成得很好,客户很满意,我认为主要就是准备工作做得仔细吧,不过一班闲人就将其拔高到方法论的高度,让我总结一下。

说实在的,我觉得方法论当然是个好东西,不过从所谓的性能测试和概念原型测试中总结出方法论来,不免让人觉得好笑。我想其实大家都不傻,这又何必呢?可是你就得做得有板有眼。

很多事情不是书上指导了就能做好的,用心学习积累经验比什么都强。写个方法论,除了指导自己和与自己差不多水平的人以外,还能指导谁呢?

首先要明确测试的目的。目的拟不出来,理解不了,或者总想着东西兼顾,乃测试大忌。有些人很重视某些小技巧和小方法,觉得那就是生存的根本,这就是所谓的只见树木,不见森林,方向都没确定呢,只记得那条路上有狼,那条路上有虎,又有什么用呢。明确目的,听起来再简单不过了,但领悟的人能有几个?

比方说这次门户测试吧,目的就是证明我们的产品将客户的交易重写在另一个数据库上了,而且此类重写需要在各种情况下都能完成。很简单,就一条,这就是目的。所谓易用性、压力测试、性能提升等等,可以说得象回事,但主测的人真要去做,那就是昏了头了,可是事实上真有很多人昏头。

目的是怎么定下来的?这就需要你懂销售和客户,还要懂当时的情形,明白什么是关键。经验积累是一回事,沟通客户,理解客户当前紧要任务是另一回事,然后将客户的任务转成自己产品的作用是第三件事。

所以第一条的第一款是了解背景资料,包括客户信息、项目信息。第二款是约见客户项目经理和设计师,可以分开来见,也可以一起见,关键是要知道问那些问题,确认自己的方向,并快速构思出测试目的,当然你若对产品了解足够多,当时你就知道目的能不能达到,从而拟出对自己有利的方向,这就是所谓的谋事在人了。第三款是和客户确认目的,这时候要很认真,也一定要让客户知道你是很认真的,确认下目的,客户可能会想着多个目的,但你要归到一点上来,若不能归到一点,则说服客户将测试分成多个阶段。

然后就可以做测试可行性研究了,算是第二条吧。有经验的测试设计师在沟通确认目的的时候就大体知道可行性了,而没经验的则胡乱答应,结果做不了,公司为什么要给设计师高薪呢,原因就在这里了,成功的设计师从来只有可行的可行性研究报告。

如果研究的结果是不可行,则必须回到第一条,重新确定测试目标,这一点很重要,任何人都有出错的时候,百密一疏,错了就赶紧回头,别心存侥幸。当然,也有不得已不得不上的时候,那就要知己知彼而百战不殆了。

可行性研究之后,便需要制定详细的测试计划。

制定计划的第一步就是收集测试环境资料。不同的产品、不同的项目所需要的资料是不同的,从这一点上也体现出设计师的价值。当然收集此类不需要面谈,最好是通过电话商量,通过电子邮件提出问题。通常客户对此类资料掌握得也不完整,所以应该计划好一个星期的时间让客户能准备好答案。

第二步是撰写浮出水面的测试计划书。计划书务求详尽,对各种情况要考虑周到,因为客户多半不熟悉自己的产品,而且测试过程中对出现的问题再求答案,则大大影响测试的效果,即使测试完成了,客户的印象分却丢了。

计划书应该有四部分的内容。一是安装和配置指南,二是理想配置样板,三是测试内容祥解,四是任务人员进度表。

通常客户很关心安装和配置指南,因此在写的时候要从客户的角度来衡量,要达到的效果是,客户看完指南后对测试就放心了。朴实无华地写出详细步骤就好了,切忌再宣传产品的优点和功能。

理想配置样板是为了配置的时候有个参考,应该运用收集到的测试环境资料来准备,最大限度地追求与实际测试时参数一致,由于篇幅巨大,客户虽无心细观,亦觉得设计书详尽有力。

由于真正测试时变化的因素很多,测试通常不能按照测试内容祥解完全地执行。这一部分是为了提醒要测的内容,定个方向而已。

任务人员进度表很重要,无论是客户还是测试一方,都应该按照此表安排人员的时间,而且在测试过程中,所有参与人员可以依据此表对测试的进度和自己当前的任务心中有数。

计划书完成后要与客户的项目经理和设计师沟通,确定他们对测试的内容和人员安排已经知道并认可。然后就可以定下时间,开始测试了。

即使准备十分周详,测试过程中依然会出一些问题,有些是环境的问题,对于此类问题,应该使得客户明白是环境问题,调动力量解决,解决过程中,只能耐心等待,沉默是金。而有些问题出在产品上,态度要诚恳,不要将责任推到开发人员身上,也不要对问题喋喋不休,静下心来迅速找到绕道的方案,然后承诺解决并定下一个汇报解决结果的时间。

测试结束后,别忘记和客户现场总结测试的结果,并定下下一步销售会议的时间。

No comments: