在阿里也差不多待了一个多月,接触的项目也很具有代表性,简单描叙一下场景吧。需求方是我们的运营同学,该项目涉及到有ETL部分和UED部分,前期,我没有进入到该项目组,详细设计阶段缺少我们测试人员,导致当进行项目之后,发现项目文档写得不具备可测试性。后期,文档修改完成之后,测试阶段碰到的最多的就是变化,需求在变,设计也在变,测试人员拖在后面,压力很大的!
场景,大致就是这样子的。具体的问题细节,应该是很有代表性的。
1. 进入项目比较晚,导致的问题就是详细设计文档,没有测试人员参与,当测试人员进入之后,发现根据文档,测试人员无法进行测试分析,编写测试案例的工作。而此时开发人员已经开发了一定的时间,所以,这个时候,开发人员配合修改文档的工作不是很积极。当直接和开发人员讨论,会看到每个开发人员并不清楚其他人的工作,也就是说开发人员也都没法完全理解详细设计文档。他们的工作模式可能是边coding边重新设计。这个是很可怕的事情。
如果这种事情发生了,怎么办?一个好的测试人员,需要在整个项目流程中,引导开发,PM,去遵守一定的流程,好的流程可以事半功倍的。当我碰到这个情况后,我是按下面的步骤进行:
第一步,与开发,PM沟通,花一个下午的时候,把详细设计文档中的问题指出来,并给出一个期望的模板。
第二步,制定测试计划,期间规定详细设计文档交付的时间,单元测试交付的时间,测试案例评审的时间,测试脚本和测试执行的时间。这个测试计划也需要和DEV,PM达成共识。
第三步,为开发人员引进一个合适的单元测试框架,给出单元测试的案例标准。
第四步,在流程的每个关键点进行把控开发的活动,不能只制定流程,而不去关心流程在运转的状况。
2. 需求变更太多.虽然说,标准的流程已经制定了,但是由于之前没有一个好的设计,后面需求的实现出入也会比较大。一般情况下,开发,测试,PM沟通之后,设计还是会修改的。那么,这个时候的测试人员一定得搞清楚,变更所带来的影响,以及测试会增加的工作量。
比如说:在项目测试的最后阶段,发现一个缺陷,但是开发人员的修改方案却是推翻之前的一个模块设计(该模块的测试已经结束),也就说该模块的代码需要重构。在进行多次讨论之后,开发人员还是需要对这部分进行变更(虽然我是反对在项目发布前做这么大的改动)。这种情况下,我能做的事情主要就集中在下面几个方面:
1. 分析, 这些改变会影响到那些模块,及时发出邮件通知影响涉及到的人员。
2. 同开发人员讲清楚,单元测试一定要更新,并保证通过。
3. 即使更新测试脚本和测试数据,进行回归测试。
4. 对之前所以的测试模块进行一次测试执行。
自己也不知道要说明什么,只是感慨一下进入阿里之后的一个项目经历,和之前有很大的不同。这里,是一个测试人员对着一堆的开发人员,测试人员需要做的就是全程跟进,了解项目的方方面面,让项目的质量得到保障。
原文转自:http://www.wangyuxiong.com/archives/51245