十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
1、这个bug我这边重现不了
创新互联公司专业为企业提供三山网站建设、三山做网站、三山网站设计、三山网站制作等企业网站建设、网页设计与制作、三山企业网站模板建站服务,10年三山做网站经验,不只是建网站,更提供有价值的思路和整体网络服务。
解决办法
Bug应该简明扼要,重点突出。如果描述存在歧义,一定要总结并尽快改进。有时会遇到概率性的bug,要告诉开发概率是多少,尽可能多的提供重现的条件。
在复现问题时,希望能大致判断几个问题点,然后和测试人员沟通下,需要如何捕获信息,捕获那类信息?是不是提供debug版本进行复现,或者根据预判的点增加打印信息版本进行复现?
2、这个不是代码问题,需求这么定义的
解决办法
需求也是人定的,如果觉得有异议,可以找需求人员询问清楚,为什么这样定义,把自己的想法告诉他们,看他们怎么决定。如果被需求说服了当然是最好的,如果自己还是不同意需求的看法,需求又不同意我的提议,那只能听他的,毕竟权力在他那里。但是我们可以保留交流的记录,证明曾经在这里发生过歧义。
3、这块是别人负责的,我负责的部分没有问题
解决办法
如果bug是由开发的项目经理来分发到程序员,那就是项目经理来面对这样的问题,而不是测试。当然,项目经理当然有项目经理的处理办法。可是,测试遇到这样的问题怎么办呢,把负责相关内容的开发都邀请到一个讨论组里,让他们自己讨论,这样更清楚,不必在测试这里中转。如果他们都觉得代码没问题,而我也有强有力的截图和真相,那就只有上交给上级领导,让他们来决定怎么解决。
4、有问题吗?(也就是开发不认为这是个问题)
解决办法
测试人员一定比开发要敏感,对bug的容忍度也要低一些。特别是一些不符合用户习惯的bug,开发总觉得无大碍。比如,一个列表默认的宽度太小了,导致初次打开,有一些内容被隐藏在后面,但是这个宽度可以手动调节。开发觉得问题很小,不影响功能,而且也有解决办法,所以不认为是bug。这个时候,就要发挥测试的本事了,嘴甜一点,说说好话,态度柔和一些。因为既然是小问题,解决起来一定不难,耐心地催开发的改过来就好。催一次不行催两次,记住态度一定要好。
5、用户不会像你这样操作的!
解决办法
用户怎么操作,谁都预料不到。我们不可能覆盖所有可能性,但是大多数用户会出现的操作,我们当然要测试。慢慢地把开发从代码的世界里带出来,带到用户的世界里,让他换个角度思考问题,毕竟软件开发不是为了实现功能,是要满足用户需求的。如果最后还是没能说服他,第一向上级反映,第二做好沟通的记录,将来备份在测试报告里。
参考资料: 软件测试中如何沟通 http://www.studyofnet.com/news/948.html