8月中旬接手了一个新项目,经过两周,完成了第一轮测试。昨天,整理了一下PPT,把该项目的业务流程和各配置项的作用,与销售,项目经理,实施,等前线同事做分享。
分享的过程不赘述,印象深刻的是最后的QA环节。
我在测试时,下意识的把测试重点都放在了系统内部的流程,一家新医院,从无到有,应该如何如何配置,摸索各个配置项,到底起的什么作用。但是忽略了在实施层面,需要考虑到的问题。
简单描述,这个系统的作用就是帮助患者预约检查。这是一个TO B 的系统,主要是跟HIS做对接。但测试时,我只简单考虑了系统内部怎么进行号源的流通,缺少了思考,在实际应用中,医院的号源怎么与该系统号源同步,医院的检查检验,怎么与该系统的检查检验进行同步。
在QA环节,前线人员,明显会更加关注该系统如何与医院现实的场景进行匹配,比如:有的医院是同一个预约台同时约所有的检查,有的医院是不同类型的检查分开预约,在该系统中如何进行相应医护人员权限的配置;再比如:如何确保医院HIS的检查数据跟我们的系统保持一致;由于没有提前进行相应的了解,许多问题我都回答不上。
意识到缺漏,在分享会后,我去找了相应的在实施现场的开发,了解现有的解决方案。了解到目前号源是由医务人员配置,医院想配几个号配几个号,无需对接;关于检查数据同步问题,我们会提供相应的同步接口,由医院调用我们的接口进行同步。
这件事最大的感触是,测试需要开阔思路,不能太想当然,只在内部系统中思考,更需要换位思考,站在实施等角度,思考产品应如何在现实中落地,在落地过程中与外部系统对接可能会遇到的问题,思考现有的产品与现实应用场景中的区别并提出质疑。
打开思路,很重要。
如果有机会跟项目,去到实施现场,近距离接触现实应用场景,或许测试可以更加完善,思路会更加开阔,期待。