让开发改bug全靠催?分享6个实用技巧

测试小伙伴们,你们有遇到下图的情况吗?

让开发改bug全靠催?分享6个实用技巧_第1张图片

这张图其实还算“温柔”的,其实有些情况下,某些测试人员或者开发人员脾气大的可能撕逼或者快干架。所以如何和开发有效沟通,并高效劝说开发改掉bug是一门学问,以下是我总结八年测试经验给测试新人的一些建议:

1、和开发人员保持友好的团队关系。这是最重要的一点!

我以前遇到一个开发,刚开始给他提bug时,他是各种抵触情绪加敷衍。后来我就私底下和他多接触,了解他的脾气,久而久之他也和我熟络起来,结果不仅不再有抵触情绪,甚至还帮我主动定位bug。其实人心都是肉长的,我们做事既要讲理,也要适当打打“感情牌”。注意跟开发沟通的语气,要有换位思考的意识,做事情对事不对人,对待开发要确保在解决bug的前提下尽量不伤和气。也只有这样,才能够很好的说服开发去修改Bug。当然有时候我们也会遇到强势的开发,油盐不进的那种,对我们的测试工作带来层层阻力,我也亲身经历过,但是这种开发毕竟是少数,如果真遇到了那就具体问题具体分析吧!

2、要确定这是一个真正的bug

不要出现因为配置原因或者是操作错误引起的“bug”,这样是会被开发“鄙视”的。最搞笑的是自己测错了版本,然后测出了老版本的问题,那就尴尬了。或者自己电脑网络问题,结果以为是服务器响应问题,这样的失误多了肯定降低自己在开发心中的地位。作为一名测试人员,我们应该树立在开发心中专业的形象。这样说话才有分量。遇到问题先别头脑一发热就去找开发询问,哪怕有些自己不确定了也尽可能自己想办法确认问题,确定是bug了再去找开发。一定要记住,我们可是专业的“虫师”?!

3、尽可能写好bug描述,方便他人就是方便自己

以前我工作中遇到过一个现象,就是同组的女测试每次提的bug都能比我解决的快,我当时很纳闷,就去询问开发人员,这是性别歧视还是怜香惜玉呢?结果开发只回了一句:“她解释的更清楚,你的需要反复核对才能确定!”从那以后我痛定思痛,在缺陷管理工具中会将bug的详情描述的特别清晰。而且咱们测试描述地越清晰,越具体,开发才会更加佩服你的“专业”。

Bug的描述尽量详细且浅显易懂,确保没有歧义,复现的步骤一定要条理清晰,你的预期结果和现有的结果,截图也要尽量标注信息且清晰。如果是特殊的测试数据,我们还需要附带这些数据。

对于复现率很低的问题,需要注明复现率,详细记录当时的测试环境信息。如操作系统、产品名称、版本、操作步骤、是否机器相关、是否产品相关等。

4、提升自己的专业技能

我刚入行时遇到一次特别囧的经历,有一次给团队的开发提Bug,结果新来的女前端跑来质问我,一个后台问题怎么提给了她前端。当时我才明白,我们测试打铁必须自身硬,必须具备对bug的基本定位能力,就比如刚说的Bug,如果我当时会F12看下报的是502问题,肯定就不会提交到前端开发人员那去了。

其实我们测试人员,首先是对业务分析的能力。要充分熟悉我们软件产品各个层面的业务,包括功能业务,代码实现逻辑,环境配置部署等。特别是做功能测试时,我们必须对所测模块的需求很熟悉,要比开发人员更熟悉。或者说一名专业的测试人员,可能比客户和PM更懂这块的规范。其次我们必须具备市面上常见的软件测试技巧,掌握主流的测试工具。比如为了更高效测试而采取的自动化测试!说到这,你应该很自然地想到也应该具备基本的代码阅读能力吧,要想成为一名优秀的测试工程师,我们应该知己知彼,知道开发是怎么个代码逻辑实现需求,从而能够更精准的定位深层次的问题。

5、测试应把握重点,切勿胡子眉毛一把抓

这点当然也是测试界特别需要注意的一点,那就是在有限的测试时间内我们应该有舍有得。我曾经在这块有过一次争的面红耳赤的经历,之前我们做过一个交通方面的OA系统,我当时为了全面保障项目质量,在产品需求之外进行了一次性能测试,结果Jmeter测出来并发100用户时系统就崩了,要知道我之前测的再小的OA系统也能承受500以上的并发。所以我当即就找PM和主要开发人员反应该问题,本来以为他们在惊讶之余会立马解决该性能问题,结果得到的答复却是:“我们这边对性能没要求,你只要保证主要的功能没问题就行”。当时初生牛犊不怕虎的我,自然不肯放过这样的低级性能问题,所以又去找总监拿主意,结果开发知道后很是生气,最后也还是按照产品需求的基本功能实现就交付了,理由是小项目时间紧,任务重,人员少,只需要保证需求的实现即可,其它性能可以放到后期版本再去考虑。

其实现在市面上很多公司都是初创,很多项目都是人员少时间紧,所以要求我们测试应把握重点,不要在无关紧要的地方测试过多。切勿为了无关紧要的“bug”浪费沟通成本。什么是重点,就是产品的主要功能和市面上该产品的主流要求,用户经常会用到的操作。

如果是需求明确的严重问题,相信只要是开发,他都会想法设法去修复它。但比如说,一些非常规操作导致的严重问题,开发人员会说,实际场景中,用户是不会这样操作的。

对于这些问题,沟通是很浪费成本的,可以把问题记录在日报中,反馈给测试老大或项目负责人,由他们来评估。再比如说一些个人界面建议,我们可以提交bug,但是开发不改,也不影响用户使用的,我们不用过多纠结,只需做好记录备案即可。

6、集中火力开炮,将遇到的问题一起问开发

软件开发行业每个人都很忙,特别是忙着敲代码的开发更是极少有耐心,问的多了甚至对你口吐芬芳,所以不要一发现跟预期不清楚的就去询问,因为在忙的情况下,很大程度上你抛过去的问题都会被无视。聪明的做法是把你需要问的问题做一下整理,集中起来问开发。如果这种方法还是不行,我教授你一个诀窍,那就是搬把椅子坐他身后,你看他能无视你到多久,哈哈!?

所以测试这门学问,不仅是要具备测试的“智商”,更要讲究点“情商”。将心比心地去换位思考,揣摩开发的内心世界,我们才能驱动开发去做他们本不愿意的事情,才能够高效地解决掉bug!

总结

外行对于程序员的认知很单一,也有很多刻板印象,但不管如何,作为测试人员的我们,自己一定要正视自己。如果我们连自嘲和自卑都分不清楚了,那发展也就仅限如此了。

所以,尽早规划自己,朝目标发展,才是上策之道,而不是怨天尤人,等到 30 岁后再去焦虑。

在企业你如果不想成为“工具人”,就不要停下成长的步伐,打造属于自己的独特价值,具备不可替代的稀缺属性,这样才能不被淘汰,也能够在遭遇变化时,随自己所愿进行选择。

下面是你需要的资料吗!

↓↓

图片

 ❤学习安排上❤

 如果你不想一个人野蛮生长,找不到系统的资料,问题得不到帮助,坚持几天便放弃的感受的话, 请及时加入群:1150305204 ,大家可以一起讨论交流,里面会有各种软件测试资料和技术交流。

你可能感兴趣的:(python,开发语言)