作为软件测试工程师,在日常工作中接触最多的当然是团队中的开发工程师,如何和开发工程师进行有效的交流是测试工程师面对的重要问题。
 
一般来说,在一个团队中,总是有开发人员喜欢和不喜欢的测试工程师,这两者之间的工作效率和效果都有很大的差异。
 
当然,不能武断地说开发人员不喜欢的测试工程师就一定是效率低下的测试工程师,或者说是不合格的测试工程师,但一般来说,那些容易得到开发人员认可的工程师在测试时总能够更好地发现缺陷和敦促开发人员解决缺陷。
 

很多时候测试人员与开发人员因为看问题的角度不同,站位不同,思维方式也不完全一致,所以会在关于bug的工作方面就会产生很多的分歧。

 

比如我们测试工程师认为是问题必须要进行修改,但是开发人员可能觉得并不是一个必须要修复的问题,或者开发最近的工作量很多,很难安排出更多的时间修改bug,或是同一个bug反复的修复,反复的又被打开等等等等问题,经常给测试和开发都造成很大的影响,也是导致测试回归进度和产品质量很难稳定的非常重要的因素之一。

 

今天我们分享一个同学总结的,与开发人员交流的“五要六不要”:

 

 这些不要做 

 

如果不紧急,不要分散开发人员的注意力

 

这点我深有感触,自己找BUG进入状态了,一旦有人过来打断我的时候,我需要花费大量的时间和精力才能再次进入之前的沉浸状态,对于开发人员也是一样,写代码的时候,很怕被人打断,这种中断非但不会增加生产力,还会令开发人员心里不爽。长此以往就会累积成隔阂。

 

别害怕寻求帮助 你不可能什么都知道

 

问别人是有没关系的,因为这比自以为是要好!不过要确保你理解了答案,不要问同样的问题两次。这对每个人都有好处。

 

不要完全相信开发人员的话 

 

您需要找到证据来证明开发人员对“一切都应该没问题!”或“我只是改了代码中的一个字符串,它不会破坏任何逻辑”的信心。

 

不要责备 不要固守消极,尝试解决问题,对事不对人。

 

没有人是完美的,错误是不可避免的。主要目标是有能力做出正面的反应,然后做好自己的工作就好了。

 

别偷偷摸摸直接给开发人员分配缺陷 

 

与跟开发人员在未经 QA 批准的情况下关闭bug有异曲同工之妙,这可能会令人生气的。

 

不要对开发人员进行事无巨细的管理

 

 “你检查缺陷了吗?”,“现在怎么样?”,“你什么时候修复错误?”。这很烦人,开发不是你的下属,别把事事都放在心上。

 

脸皮可以厚一点,不要情绪化,不以物喜,不以己悲,不需要对别人的无意间的言行睚眦必报。

 

你要学会同傲慢的人打交道,它实际上可以应用于任何人。这就是为什么厚脸皮和委婉的表达是必须的。

 

 可以这么做 

 

与开发人员交流知识 让他们了解你的测试方法

 

每个与你合作的开发人员,你会如何进行测试,这可以帮助你避免部分错误。但是,由于一些原因,并不总是可行的。

 

学会说服 

 

如果你想在工作中得到一些非测试方面的提升,这是一项有用的技能。寻求支持并将您的计划变为现实,不过如果你在你的陈述中感到孤独,也许你的计划或想法是有改进空间的。所以,不要为了说服而说服,让别人接受你并不总是正确的事实,学会倾听和倾听你周围的人。

 

准备好为你提的bug辩护 

 

有时候你必须捍卫需要修复的缺陷的重要性。但是你必须在你的陈述中说明自己的观点,让别人信服。随着时间的推移,这会让你得到其他人的信任并节省公司的资金成本。

 

在压力下保持冷静 

 

这很难。当每个人都不断催促你或你的团队时,你很难不乖乖就范。然而,说“不”是我们工作的一部分,即使这不是流行的观点。当然如果有人把你推到墙上或用枪指着你的头,这条规则就不起作用。

 

在bug描述中要准确 

 

如果可以,请使用开发人员的语言。在其他情况下,让你的表述尽可能的简单。它应该是瑞典语中的“lagom”。具有良好的规模结构并为开发人员提供足够信息,让别人知道你描述的是到底是什么。

 

鼓励队友深入了解产品,团队中的这种意识将减少愚蠢的bug数量。根据我的经验,低级的bug会消耗大量精力来报告它们。这些bug最好直接就预防住,让我们专注于更重要的事情。而不是让我们报告错误的*字体大小,*测试的边缘情况、安全性、性能等。

 

要有耐心,不是每个人都是好相处的,要学会应对困难的、自恋的人。这是适用于任何人的一般规则。