在产品测试中,开发提测版本时过于简单,信息传递不明确,容易造成测试后期执行不顺畅,从而增加测试与开发沟通成本,如以下案例:
1、某一功能优化,服务器端新旧功能由两个不同的开发完成,涉及两个不用的测试服务器。新功能提测的时候,开发未说明测试环境,测试延用之前的旧服务器,发现部分功能异常,测试针对该问题进行定位、沟通占用了较长时间,最终确认是测试环境问题~
2、开发提测模块list信息不详细,测试无法明确哪些提测了?哪些没提测?
问题虽小,但积累多了就占用成本,于是需要测试与开发约定提测内容规范。
下面对版本提测内容做下总结:
1、基本内容
要求说明:
①版本号及版本提交的时间;
②本次版本(每次迭代也算一个小版本)实现(修改)的功能点一一列出;
③各功能负责开发人员;
④未提测模块及预计提测时间说明;
2、对应版本的代码分支路径信息、打包路径或编译后的文件(如Android应用apk包)等。
3、如果涉及到配置安装软件或环境的,还应该有相应的部署手册(或环境配置说明)。
部署手册(环境配置说明)测试要求:
①应该尽可能详尽,如果测试人员发现bug,也应记入缺陷管理系统。
②测试人员严格按部署手册进行环境部署,如因部署手册出现问题导致后续步骤无法进行的,应打回相应开发人员重新提交版本,并邮件通知大家(包括直属领导和项目决策人)。
③如果部署手册出现问题,但因为项目时间紧急,测试人员能自行搞定的,也可以部署后把缺陷记录上,在下次回归时做测试。
④部署手册不能由测试人员修改,部署手册出现严重问题影响用户安装部署环境的,测试可反对发布,并邮件通知大家。
4、如果涉及到数据导入(比如大量数据测试),还应该提供相应的sql执行语句;还包括数据库的定时任务、储存过程等。
5、开发单元测试用例和自测报告。
6、如果涉及到用户使用手册、还应该附上用户手册等。
7、版本其他(如shell脚本、涉及到的插件等)。
8、影响范围,即代码实现(或变更)的影响范围说明。
以上都应该分类固化下来,过后每次提交版本后都应该有一个版本检查测试。根据实际情况,以上版本内容可以经过大家一致同意后做适当的增减。
最后,提测申请应该以邮件的形式发送给大家(包括测试负责人,测试执行人,项目决策人)。
当测试拿到提测版本后,首先需要检查提测内容项是否完整、齐备,无误后则开始做冒烟测试。
其中某一个环出现问题(如功能出现大缺陷,导致后面功能不能使用。或部署手册有问题,不能按上面完成环境部署等),导致后续没法测试或测试困难的,直接打回开发重提版本。
冒烟测试通过后,再进入正式测试阶段。这样规避了开发提测质量过差,浪费过多的时间沟通。