很多时候,测试人员把缺陷描述不清楚或者缺陷有歧义,开发人员看不懂,不明白具体的意思,加上开发人员任务重时间紧,很容易产生逆反心里,这就让开发人员对测试人员有看法,以后递交的缺陷认可度就大大降低了。还有就是要减少随机测试,一定要保证递交的缺陷能够重复出现,最好要有截图、图片或者用数码相机照下来,让开发人员认识到这个问题确实存在,并且更具说服力。
d). 做好版本配置管理工作,保证测试环境的准确性:软件测试环境搭建
很多同事发现的缺陷,只有在测试环境下重现,而在开发环境下不能够重现。这样的缺陷开发人员往往是看不到的,他们很容易得出结论,说测试人员递交无效的缺陷而被拒绝,大部分情况发现是版本弄错啦!!我们唯一能做的就是做好源代码的配置管理工作,保证测试环境版本的正确性和独立性,自己编译自己部署测试环境。只有这样,才会减少无效缺陷的递交,避免“费劲周折”说服开发人员修改缺陷。
4. 正确分析测试中的软件缺陷:
a). 为递交的每个缺陷准备几条充足的理由:
一般情况下,我们提到一个Bug时,开发人员都会说出很多可以不修改缺陷的理由,尽量搪塞住我们的口,要求我们关掉缺陷或者置为无效或者延期到下一个版本。如果你很牛,你可以为自己递交的每个缺陷准备很充足的理由去说服开发人员;如果你不是太强,那就可以求助部门同事,集中测试部门团队的力量,想一些好的、站得住脚理由,详细介绍给研发人员听,只要我们递交的Bug,每个都具说服力的话,我想他们也会尽快修改的。这种方法还真是不错,大家不妨试一试。
b). 详细分析缺陷给项目带来的各种可能影响或缺陷风险:
比如说,我们递交一个缺陷,如果研发的觉的这个缺陷可以修改或可以不修改时。我们一定要给研发分析修改这个缺陷的必要性,不修改,对客户带来哪种可能影响或存在哪些风险。要在修改缺陷的代价与修复成本的关系上去衡量。相信,当我们对缺陷分析的很详细时,研发人员一定会修改Bug的。
5. 做一个聪明的测试工程师:
a). 注意和研发人员的沟通技巧:
如果测试人员没有做过开发工作,理解也许就比较片面。有的测试人员,对待问题没有耐心,性情比较急,也是常有的事。如果没有较好的沟通技巧,也许就是几句话的功夫,就和同事争吵了起来,弄得大家都比较尴尬。个人建议:谈话时,要注意沟通技巧,要有换位思维的方式,做事情对事不对人,处理事情一定要有一颗宽容的心。只有这样,才能够很好的说服研发去修改Bug。
b). 和研发人员搞好私人关系,做研发的听众:
比较明智的测试人员,一定要学会倾听研发人员的心生。很多时候,开发人员碰到工作困难的时候,很希望和人倾述,如果测试人员是他的听众,那么你们的关系一定会不错。搞好了私人关系,工作中你递交的缺陷,他们就不会那么斤斤计较了,毕竟关系是基础,关系好了好说话呀,在中国就是如此。如果私人关系好了,说服研发修改Bug就是很容易的事情。不过得提醒一句:不能因为关系好就把Open的缺陷给关了。
6. 抓住时机,不要错过千载难逢的好机会:
a). 求助公司上层领导:
很多时候,测试到后期,开发人员把缺陷也修改的差不多了,公司领导(比如说老总、总监、项目经理或开发经理)就会随时来测试部门,找测试经理或负责人了解项目测试的具体情况。如果有一些问题都是争议问题,作为测试Leader的你不妨给领导聊聊,把更高层的人拉进来为测试部门说话,为测试部门撑腰,但是凡事都有一个度,不能太过分,否则很伤同事的和气。
b). 要求客户代表援助:
很多GUI的缺陷或可改可不该的缺陷,可能作为客户使用不是很方便。我们可以和客户代表聊聊这样的缺陷,如果客户代表同意这样做,那没问题,可以不修改;如果客户不同意,他自然会直接找项目经理或高层人员协调解决这个问题,这就不用我们测试人员操心了。因为客户就是上帝,这招不错吧!!!
我目前想到的就这么多,希望同行指正!!!
文章来源于领测软件测试网 https://www.ltesting.net/