前段时间收到一个朋友的信息,说他们目前正在实施ERP系统,已经到了集成测试环节了,但整个测试过程下来并不是太理想,很多接口不通,功能也还在开发或修改中。
其实早些天之前我就收到他发给我的集成测试脚本,让我参考给些意见。虽然我不了解他们公司的业务,但从这份脚本来看,其实做得不怎么样,完全达不到合格的标准:1、没有描述清楚当前测试的业务具体内容、业务场景、特殊点以及涉及到的系统;2、相关系统操作环节的事务代码不明确、操作环节的关键点以及期望并没有描述清楚;3、相关步骤责任部门、岗位、操作人不明确,尤其要注意上下节点部门之间的信息对接方式;4、整个操作过程只列出了ERP系统很核心很标准的操作,但平时操作流程节点里,会有不少查询和报表的需要,这里也没体现;他们公司实施了大半年,得到了这样的结果其实是很有风险的,集成测试不过关,侧面反映了这个项目的质量堪忧。集成测试实际上对前面蓝图的实现做的一次彻底的验证,蓝图是否真的合理、业务上能否跑的通就能够在集成测试环节体现出来。所以说,把握好集成测试大关,不让整个系统的落地实现偏离蓝图和业务的轨道,ERP就成功了一大半。当然,不要为了测试而测试。曾经我就遇到过一些乙方团队在做集成测试的会议室上,一开始就打开ERP系统,对着集成测试脚本一步一步操作下来,操作非常顺滑。对不起,这个叫操作练习,不叫集成测试。真正合格的集成测试,是需要边测试边讲解业务流程和场景的,让每个参与测试的关键用户都非常清楚他们在测什么东西,要非常明白自己所处的角色和作用,知道自己从哪里获取信息,结束之后可能需要谁对接等。测试环节的上游和下游都要交代清楚,包括数据流向,部门沟通,数据验证等。这里举个例子,仓库人员在收到一批货之后,查看货物标签,就能知道是哪个供应商、什么货物、多少量、哪个采购订单入的。扫描二维码,PDA能够看到相关的采购员及订单信息,便于核对。输入点收数量,能够正确入库。之后通过系统查询就能知道有多少量已经入到仓库里了。系统发出通知,采购员能够第一时间知道订单已经做了入库。集成测试过程实际上也是一次统一系统认识,统一业务理解,消除认知误差的过程。不要为了测试而测试,不要只停留在系统操作层面。各个部门关键用户要清晰他这个环节的上下游都是谁,提供什么数据,明白自己做这个动作是为了啥,目的是啥,不做会怎么样等等。关于那位朋友的问题,我也只能依据有限的信息给出自己的建议:不妨把一些没来得及做或者没做好的、相对不重要不紧急的功能对接分两期进行,第一期先不上,等系统上线稳定1-2个月之后再继续第二期对接优化。不要为了工期而牺牲质量,用户有信心,质量有把握,系统稳定才是主要的,适当延期1-2个月也是可以的。