关于软件提测环节的思考
一、背景
公司有产品、研发、测试三个角色,总体流程及分工如下:
1、设计阶段:产品根据战略目标、用户或其他人员的需求设计产品功能,出具产品业务流程图、产品原型及UI;
2、研发阶段:研发拿到产品设计后,评估工作量,开发实现产品,测试拿到产品设计后,设计测试用例,评估测试时间周期。研发周期及测试周期加起来,即得到产品何时上线的时间。
3、测试阶段:开发人员完成产品开发后,提交给测试人员测试,测试人员测出bug后,研发人员修改,此间会往复几次,待产品稳定后即提交上线。
二、面临的问题
主要面临的问题:开发自测不足带来后期测试周期太长,导致产品延期。
1、研发人员在提交测试前未对产品进行充分的测试,导致测试阶段的问题很多,产品测试周期变长,导致产品延期;
2、作为项目负责人,迫于项目进度的压力,可能会在测试不充分的情况下即提交上线,导致上线后产品存在较多bug,影响用户使用;
开发人员心理分析:
1、大部分开发人员能够在写代码中找到乐趣,厌烦繁琐的测试工作;
2、开发人员过于自信,认为自已的代码可能没大问题,即使有问题,待测试人员测出来以后再改也不迟;
3、测试工作要花费自已的许多时间,有的开发人员会认为这样的工作对他没有任何价值;
4、没有认为测试工作就是开发工作的一部分,认为完成了开发就够了;
5、没有做好自测,也没有给自已带来严重的后果 。
测试人员心理分析:
1、希望开发人员自测,降低bug数量,缩短测试周期;
2、希望将重心放在更有深度、有挑战的工作上,比如性能测试、自动化测试、兼容测试等;而不是在为开发人员补漏;
3、希望开发人员能够快速的修改bug;
对后续工作带来的其他影响:
1、测试工作推进不畅:主流程不通,导致测试工作推进较缓慢,一些问题需要改了后才能继续测试;
2、开发人员没有对自已的开发的内容负责,依赖于测试人员找问题,带来自身水平提高缓慢;
3、测试反馈较多的bug,会给开发人员的自信心、成就感带来不利的影响,反之,如果bug少,开发人员会更有自信;
4、测试周期延长会给测试人员的工作积极性带来不利影响;
5、影响团队的工作氛围,bug多了以后,干系人会互相推诿。
三、如何解决
理念的普及
只有每个人将自已的事情做好,才能提高团队协作效率,提高自身水平。
制度保障
制定提测环节规范,明确提测时要达到的标准,在提测时增设具有仪式感的软件演示环节,由开发人员演示,测试人员验收,达到提测标准视为提测成功。具体细则初步考虑如下:
1、设计软件提测单,包含两部分内容 :
(1)开发人员自我检查清单 :开发人员提测时需要自检我检查的内容 ,这些内容大致包括:版本号、任务是否完成、软件主要功能及流程、单元测试是否编写、测试环境部署情况。其目的主要是让开发人员提测前确保自已的工作都已经完成;
(2)提测结果确认表:列出本次提测演示的主要功能流程,由测试人员打勾确认,最终给出提测结论,通过或不通过。
2、软件提测单需由开发测试人员双方共同签字确认,测试人员一旦接手以后,则应在计划的测试时间内完成测试并提交上线请求。
反思:对测试人员的考核可以用这个标准。
奖励惩措施
1、现金奖励,从部门费用里面出,按时提测成功,即奖励;
2、在月度评价中体现,要设计月度工作检查清单,该清单反映每个人当月的工作绩效,如,主要工作完成情况,是否有延期,迟到多少次,请假多少次,主管评价等等,这个检查单可以暂时不和工资挂钩;
反思:月度考评一直没有做起来,根本原因是没有和考核工资挂钩。
3、后续再考虑分段奖惩,比如提前1天,奖励加100,延后一天,奖励减少100;
四、下一步行动
1、由测试部整理该规范,下发给大家;
2、开专题会讲解为什么要这样做,这样做的好处;
3、先试行一段时间,在试行过程中再完善该制度。
原创内容,转载请注明出处!