怎样测试才能少被开发怼？

我们测试中发现或提交的bug时常出现被开发同学“怼的现象出现,所以我会先自身找问题,为什么会被怼”,怎么才能不被“怼”,然后怎么才能让他认清沉默“嗯~ ,确实,这是个bug”,就之前被怼”过的经验来分享下:

开发人员“怼”测试同学的直接原因:

1、Bug描述缺少辅助截图:
Bug描述需增加辅助页面截图, - -方面表达更清楚,减少文字描述 ;另一方面,某些偶发bug留下“事故现场”的证据很有必要,当然如果有个录屏短视频或日志上报,就由不得他不信了。

2、用词不准确到位:
如果公负责测试的同学不是技术出身,无法完全用专业术语,也要尽量把bug和正确结果描述的清楚到位,否则反而会增加沟通成本,效果还不会好。当然,如果测试也懂技术,所有问题都不是问题,但现实中可能吗?

3、前端、后端、设计问题在Bug中未区分
这是见测试功底的地方,测试人员的经验一般从这里体现的淋漓尽致。 还有需要对于Bug做出正确的优先级排序

4、某些问题的解决方式没有变通:
第一种情况时,不要慌了手脚忙着策划新方案,而是先去和程序员们沟通、听取建议,咨询有什么方式可以在变动最小的情况下达到目的(注意不一定是结果)。
第二种情况就相当于提新需求了,这里是被开发怼的最多的地方之一, 所以在跟开发沟通时要三思而后行，最好是纳入需求池在下个版本迭代中完成,这样的处理方式是你好我也好。如果测试的时候总提新需求，暂不提程序员的心理阴影面积,产品开发节奏会全盘打乱。

5、测试时怎么没有测试出来这个问题?
出现问题首先要理性的分析问题: 1 ,是测试漏测了,没有测试到位?2 ,还是当时通过测试后重新上线了什么代码引起的?
如果是测试漏测了,没有测试到位,敢于承认,承担自己的责任,总结经验,完善测试思路,避免下次再犯此错误。
如果是测试通过后上新代码影响了, 在先解决问题优先,处理后同时相关同事,在后续上新代码请尽可能的预估影响范围,并告知测试回测后上线。

6、这个功能你测试了吗?
只要是功能上线,作为测试的职责和负责,在测试用例范围内的都必须测试通过,除非测试用例真的没有覆盖到,否则被开发同学问道这个问题很难回答。

---------------------------不很华丽的分割线----------------------------

开发人员“怼”测试同学的根本原因:

1、说白了就是面子问题…
2、开发人员对其所写代码有主观认同感
3、人通常习惯之下会对自己所犯错误视而不见或者拒绝承认。

同样的,在软件开发领域,程序员们在耗费大量心血编写代码,完成工作之后,他们会固执的认为自己编写的代码运行良好。
他们对待其开发的应用程序就像对待自己的孩子一样, 拒绝承认自己的孩子有什么不好的地方。这就是为什么软件开发人员难于发现和改正自己的错误。

4、开发人员对软件过于乐观的心态
开发人员进行开发的目标是将软件所需的功能完美的展现出来。
当程序的功能运转正常的时候他们会自我感觉良好,因为他们的主要目标就是功能二字。而测试人员与他们想的却不-样。
测试人员通常会从不同的角度切入进软件内部,打破程序员们惯有的思维方式。他们的目标是通过各种不同的测试用例把软件潜在的不足之处暴露出来。

开发人员与测试同学的根本差距:

1、两者思考维度不一样
开发人员专注于程序的功能,并在现有需求和设计的指引下开展工作,往往不会从业务逻辑和使用者角度去思考功能完成后的实际价值。软件测试人员至少会站在使用者角度去发现-些需求和设计上的问题。这是两者思考方式的区别。

2、开发人员擅长修复但不擅长拆解
开发人员只擅长代码的功能测试和代码修复,如果程序运行正常,那么他们的测试就结束了。
而事实上,测试人员的主要工作是将应用程序拆解,从每个小块之中找寻那些不易发现的bug ,并帮助开发人员了解那些特定的功能应当是怎么样的。

3、开发人员缺乏从测试的角度思考问题

为什么我一直推崇开发人员做单元测试和功能测试包括接口测试,是因为在长期的积累当中你会提高对自身程序拆解的能力,对其他模块理解的能力,这是一个从微观逐渐到宏观的思维方式,如果这种思维方式不建立，开发人员会-直受限于程序员思维而不能自拔。
术业有专攻,每个人都有自己擅长的领域。
许多开发人员认为测试人员是在故意给他们找碴挑刺,而事实上,我们都是在帮助公司的产品在找问题、解决问题。

写在最后：请记往，测试人员永远是开发人员身边最好的朋友。