需求分析阶段和测分阶段的一些想法【原创】

上一篇 / 下一篇  2009-06-06 12:28:27 / 个人分类:07 工作总结

项目终于结束了,这次经历的项目规模应该是来这里之后的最大型的项目。又经历了一次项目之后的感想。

项目类型:大型重构型项目。大部分是老大业务规则,小部分的新业务需求(这部分内容是少不了的)

STA:测试分析人员,项目测试负责人

---------------------------------------------------------------PRD(需求分析)评审阶段-------------------------------------

自身不足:

1、对prd需求理解不深入,有个总体感觉觉得不好,但是实例却举不出来多少
2、对于prd没有完全弄明白的情况,很多问题都还是未知数,却在prd评审这关上轻易放过了
3、和PD的沟通很少。因为一开始就认定和PD沟通没用,所以宁愿选择了和业务方去沟通。并且和业务方沟通的结果没有及时反馈给PA

改进方法:

1、prd阅读阶段,加强和PA的沟通。当然和业务方进行沟通也是有必要的,但是这个沟通的过程必须拉上PD在场。
2、prd评审期间,如果因为时间比较短对prd阅读不充分,那么一定要把这个信息告诉SQA,如果提不出问题来,那么请允许我以结构不清晰,需求描述太跳跃等理由去拒绝prd的评审通过,为自己争取更多一些的prd阅读时间。
3、prd阅读期间需要将一些阅读中的问题及时反馈给prd,并要求及时的调整prd文档到你所预期想要的。

后续建议:

1、prd描述必须有清晰的体现流程的结构
2、prd的需求描述必须集中,比如属于文件导入的需求点全部都应该放在一块来描述。
3、prd仅包含本次需要实现的内容。像改造型项目,老的实现逻辑我们可以去老系统看,prd里我们只关心我们新的系统需要实现成什么样子
4、PRD的粒度问题
测试用例有粒度的问题,prd同样应该有粒度问题。我觉得我们以前的prd文档肯定是粗粒度的,所以我们才有了测试分析这么一个角色,去分解这些粗粒度的需求。但是实际上prd应该是细粒度的。但是越细pd花费的时间越多,那针对有些项目,前期时间比较短,那么需要明确prd的一个粒度问题。prd要细到什么样的程度,也是作为prd评审的依据之一
5、prd的迭代问题(建议放在项目评分机制中)
开发过程有迭代,prd同样需要迭代的过程。prd文档并不是prd评审通过之后就没事了的,我们不能要求prd文档覆盖的需求点是100%的,我们也允许后面的需求增删改,但是每一次的变动,都需要实时更新prd文档,并且及时通知到整个项目组。开发过程中,有的时候是业务方有需求要增加,有的时候因为开发设计的问题也会影响到需求变更,所有的这些pd都要及时做好跟踪。
6、需求跟踪表:对于有业务方加入跟踪项目特别受用的一点是制定需求跟踪表,引导业务方有需求不要直接找开发,由业务方填写需求跟踪表。并及时去要到该表明确需求,同时也需要把这个信息及时告诉PA让他即使更新文档并通知到整个项目组。
7、问题跟踪列表:STA从这个阶段开始就要准备一个问题跟踪列表,把项目过程中任何待明确的问题记录好,内容可以分成以下几个内容:日期,业务点,问题描述,确认结果,确认人,是否明确。每天都需要去跟踪这些问题的解决情况。确保当天的问题当天解决、

---------------------------------------------------------------测试分析阶段---------------------------------------------------

自身不足:

1、测试分析是直接在QC的需求里完成的,然后最终的文档是直接从QC导出,导致文档结构目录像臭裹脚布,很长很长。开发都看晕了
2、测分文档没有进行评审,而是就发项目组进行了确认。只有业务方给出了建议
3、后续过程中确认的需求点没有坚持做完更新
4、测分阶段对于外围产品线的配合问题没有及早发现并且提出

改进方法:

1、测分应该站在一个更宏观的角度去看问题。测分阶段可以先不清楚内部具体的细节,但是必须先和PA以及系分沟通明确对外围产品的影响,明确好其他产品线的配合点并及时做好沟通安排。
2、测分评审必须要推动项目组去举行。确保测分文档的质量。

后续建议:

1、测分文档同样要求结构清晰。功能描述点集中
2、测分文档里最好先回答我两个问题:这个功能是谁在什么情况下用的?如何用的?
3、测分文档要有业务流程图。即便是prd里已经有的,你也应该粘贴过来,如果没有,那你就自己画出来,并标注序号
4、测分文档的规则说明尽量针对业务流程图的某个步骤来进行说明。
5、测分文档同样需要有及时的更新版本,在每个版本里标注变更内容。这个点需要SQA加入监督一下。(这点做到很难,希望下个项目我能做到!!)
6、将测分评审进行到底。但是建议测分评审不需要全体项目组成员,只需要关键人物,业务方,PA,系分,相关测分即可
7、测分文档一边书写一边可以让身边的人帮你看,随时给你一件,采纳好的意见,实时更新你的文档到最佳状态

---------------------------------------------------------------测试计划阶段----------------------------------------------------

自身不足:

1、自己本身有很强的计划意识,并且一直坚持计划一定要细,同时也有制定出详细计划,但是在计划的执行和控制做的还不到位并且自身测试任务计划性比较薄弱
2、项目过程中对项目测试重点内容的把握还不到位,这样必然导致做出来的计划不可执行性,同时会带来资源问题

改进方法:

计划你要不就不要做,做了你就好好的按照着去执行,并且后续要注意做好监控,及时和组员沟通,获取计划执行进度情况,及时做好计划的更新。

后续建议:
1、大型项目计划不需要细化到天,可以做到细化到周、这周内的工作任务大家可以自由调整。
2、制定计划的时候除了根据不同的人同的能力去考虑,还需要考虑不同质量的prd文档和系分文档。如果前期工作做不好的话,那么需要在测试计划中严重考虑详细设计,需求沟通的时间。目前感觉这两块在过程中也是占用很大比例的。
3、测试用例执行阶段的测试计划依据必须是来自于用例的。利用好qc的测试实验室功能。把测试实验室和计划关联起来。这样计划的监控会更准确
4、STA如果本身有测试任务的,在制定计划的时候绝对不要再给自己安排很多的测试任务。

---------------------------------------------------------------用例设计阶段----------------------------------------------------

自身不足:

1、组内的用例规范没有很好的统一
2、组内的用例粒度也不统一
3、前期组内用例不完整,拖到项目结束之后才来补充用例

改进方法:

1、用例规范和粒度问题没有很好的统一,关键是每个人的认知度不一样,所以需要花时间和组员在这方面达成一致意见
2、在用例阶段必须保证用例的完整性。不要认为哪些用例是可以不用写的,只要是改造到过的都需要写测试用例

后续建议:

1、对于用例规范和粒度问题需要前期和组员沟通,统一意见。
2、用例设计前期必须要去和开发沟通实现逻辑,如果开发没有详细设计,那么非常好用的办法就是自己来画时序图的方式来和开发确认。
3、确认开发实现逻辑的过程中需要思考去发掘设计当中的问题,你的想法要及时提出来和开发进行沟通。这个就是给设计提bug。
4、定期进行组内用例review,确保用例的完整性和规范性。
3、用例设计和执行阶段,建议测试尽量离开发和需求方近一些。确保信息获取的及时和准确,也能确保自己参与其中(工作模式问题)
4、用例设计的粒度问题。坚决反对太细的原则,一定要考虑用例的可维护性。还有反对那种n个用例内容写了一大片,实际其中只有几个字的差别的用例。这种用例可维护性极差。对于相同的数据准备步骤和操作步骤,建议提取到上级目录里。
5、用例评审建议单对单的模式。或者一对多。找和你评审内容相关的人来进行评审。和他们面对面的去沟通,这种情况下,测试和开发都会一起思考。以前的评审模式很多是走形式。

---------------------------------------------------------------交付测试阶段----------------------------------------------------

后续建议:

1、 在qc里的用例中添加是否交付测试项,并且每个测试用例,加上对应的开发,然后导入到测试实验室,让开发自己按照交付测试用例,去自测,自测通过才是交付测试通过了。
2、 充分利用QC这个方法挺不错的,但是建议以后的项目在交付测试时候,在测试计划里添加一些常用属性项,不要在测试实验室里添加。
3、交付测试结束,要及时发送交付测试结果报告。

---------------------------------------------------------------用例执行阶段----------------------------------------------------

自身不足:


1、宏观大的控制方面较薄弱
2、和其它线关于有交集的问题沟通方面也有问题。

改进方法:

1、本身有测试任务的STA不要太关注个人的任务,要站在宏观的角度去看项目的进度情况。因为不代表你自己的进度没问题,就是大家的进度没问题了。也不要听组员片面之说,一定要自己去想办法了解真正的执行进度情况。

2、碰到和其他线交集的问题的时候,先想一个问题:我能做什么,如果我来做我的困难是什么。需要及时将这个困难反馈给总STA。资源问题找总STA去负责解决

后续建议:

1、用例执行过程中,要及时的和业务方,PA和开发保持沟通,因为这个阶段需求,设计时刻在变,你得想办法及时获取这些变更,同时要做好督促PA和业务方以及开发将这些变更通知到整个项目组。这里我觉得在项目初期必须明确谁来做这个事情,建议可以让PM去负责。这个也建议加入项目评分里面去
2、面对执行期间的变更,需要及时调整计划,更新测分文档,维护好用例
3、执行期间计划的调整不仅仅是考虑需求或者设计变更之后的测试执行时间,还需要考虑变更之后,文档维护和用例维护的时间。
4、执行期间很很重要的一件事情就是总结。不要把总结都放到项目结束,一定养成在项目期间就做总结的习惯。这点很受用,帮助的不仅是你自己,还有其他的测试,甚至是开发
5、基于完整的测试用例的大前提,每个测试阶段要建立好QC的测试实验室,并把测试进度情况通过实验室体现出来。这个也需要在前期和组员约定好。测分同学要做检查
6、本身有测试任务的STA一定要花时间去自己了解组员的执行情况。(这个如果测试实验室建立的好的话,这个是个很好的办法)

---------------------------------------------------------------后续跟踪---------------------------------------------------------

后续建议:

后续线上问题跟踪,很好的办法就是主动和业务方保持沟通。告诉业务方上线后的问题及时发给测试一份,然后STA要加上测试跟踪人,去跟踪这些问题的解决情况。并且要及时做好分析工作。


TAG:

 

评分:0

我来说两句

Open Toolbar