我们看看一张发现缺陷的时间和缺陷修复成本的关系图,下图,其中,横轴表示项目开发周期时间阶段,纵轴表示缺陷占比。如下图所示:
从图中,我们可以看出越后期修复缺陷的成本就越高,且指数增长,而缺陷主要是开发前期引入的,且前期缺陷修复成本很低,所以我们应该知道,测试越早越好。
测试的对象包括文档、数据、程序,即测试贯穿软件开发开发周期,从需求开始到编码到验收测试结束,包括但不限于对需求、概要设计、详细设计、源码、可运行程序、运行环境的测试。所以,产品经理应该从需求开始阶段就进行测试产品,当然,专门的测试人员也应该从需求开始阶段就参与测试,产品的相关人员越早参与进来,对产品的需求理解就越透彻,还可以对需求二次分析补充。
当然这里我们主要讲产品程序可运行后的相关测试,毕竟编码前的需求评审、原型、UE、UI的测试,这是每个产品经理必须具备的技能,编码期间的单元测试集成测试主要是开发人员实施,所以我们主要是讨论产品程序可运行后的相关测试。
产品程序可运行后开发人员交付build给产品经理和测试人员的测试流程一般为用例测试(是否符合需求文档)、探索测试(是否存在隐患bug)、其他测试(兼容性、安全性......)。
产品经理和测试人员沟通需求或者反馈产品的bug时,经常听到测试人员说的脚本录制及自动化测试的一些测试概念上名词,经常会说什么这个功能模块采用黑盒测试的流程分析法就知道bug的位置了,这个时候产品经理就懵逼,感觉沟通不下去了,产品做不下去了。
产品经理懂得岗位的相关上下游知识,可以更好的处理好工作,比如和测试人员沟通需求时,测试人员会说文档测试通过了吗,或者说这个等到集成测试后再系统测试验证这个问题吧,这些测试上的名词,如果你懂的话,那么沟通起来就会很顺利,你就不会去问什么是文档测试,什么是集成测试,既节约时间,更主要可以让产品的相关人员都能清楚地理解需求。