📝 面试求职: 「面试试题小程序」 ,内容涵盖 测试基础、Linux操作系统、MySQL数据库、Web功能测试、接口测试、APPium移动端测试、Python知识、Selenium自动化测试相关、性能测试、性能测试、计算机网络知识、Jmeter、HR面试,命中率杠杠的。(大家刷起来…)
📝 职场经验干货:
1. 起因
相信绝大多数身为团队leader的同学都知道,在日常工作中时刻关注团队的发展和提效是至关重要的。无关乎岗位责任,团队中的每个成员其实都发挥着关键作用,但有时候我们都会面临各类的挑战,今天就借着一次契机,与大家讨论我认知中的测试团队中的快速沟通机制与能力提升。
这个还得从前一阵子讲起,因为我们团队的组织架构是三层的,所以日常博主与测试执行团队的成员之间交流不太频繁,工作中的交集也较少。碰巧那段时间新入职一个小伙,在一次测试部门例会的过程中博主注意到一个情况,这个小伙对于工作事项的描述较为的薄弱,很多时候是有点词不达意,关于这个也是事后找到了对应的测试主管来询问情况,但鉴于小伙比较优秀的大厂工作经验背景与项目背书,就决定再观察一阵子。而通过日常的一些有意的观察与成员的项目成果汇报,发现小伙的这个习惯是在上一家公司就已经形成,而一些原本可以避免工作差错,即测试过程中的一些问题可能是由于小伙在描述Bug、传达任务时或描述事务不够清晰而引起的。而这,并不是一个批评,而是一个机会,一个我们可以改进的机会。
2. 沟通
在日常的测试活动中,沟通作为一个连接各个团队的重要信息交换手段,应该是每一个测试人员都需要利用好的软技能之一。如何打造良好的沟通环境与机制其实是我们所有从业者都应该关注的一个课题,平日里博主有空都会在经过测试团队的工位时有意无意的听一下成员之间的工作事项交流,其实一个测试人员的工作成果优质与否从他的日常沟通与表达是否有条理这一点就可以可见一斑。而且沟通的能力高低在从测试职场的角度来说,其实很大程度上影响着软件质量保障活动的成功与否。比如产品的需求与业务是否可以被正确有效的理解、提交的缺陷是否可以被快速正确的提交、是否可以做高效的风险管理、是否可以正确的优化自己的工作流程与技巧,这些因素都对产品质量保障活动的结果产生着不可忽视的作用。
既然沟通在职场中如此重要,那么如何建立快速沟通的机制就显得相当的有必要了。这个和日常生活中不同,在这个快节奏的社会中,工作场合中的沟通往往需要更多的是快速、有效、通达。所以我们在日常工作中就需要注意以下几点:
-
清晰的目标与信息:在质量保障的工作中,确保你明确自己的沟通目标。比如发现了一个Bug,不要一复现就去找开发,如果对Bug的描述或复现事项不明确且描述不当,很容易就被开发踢皮球或甩锅,长久下来你在工作场合中的人设也会慢慢的变得不可靠,这一点是很致命的,一个测试都不能给到开发信任感的话,如何让使用的客户安心的去使用公司的产品呢?所以千万不要让信息模糊不清或充斥无关紧要的细节。其实精炼和简洁的信息更容易理解和回应。
-
主动沟通:这一点其实很多的测试人员都做的不太到位,这里的主动沟通不是指测试执行中与开发的主动沟通,这么基本的不称为主动沟通。在我们的整个软件项目过程中,测试人员是否可以通过自身来驱动开发进行有效的质量控制与保障才是每个测试应该尽力去做到的事情。主动沟通亦是如此,在需求阶段,是否对产品提出或评审的功能有所质疑或自己的想法、在开发阶段,是否有主动的推动或协助过单元测试开展、在测试收尾阶段,是否有主动的优化或复盘自己的工作成果与感受等等等等。
-
语言简洁明了:很多人会说自己嘴笨,包括博主自己的团队成员中也有这样的同学。其实这个与嘴笨真的没有太大的关系,比如在与开发或项目成员描述一些Bug或问题的场景中,有些人就会反反复复的用不同的词语来描述同一个事情,听起来罗嗦无比但又抓不住中心,碰到脾气不好的还容易被打断。那么针对这样的情况,我们也可以做到说话简介明了吗?答案是肯定的,而我们需要做的就是把节奏放慢,做减法。在我们与其他人沟通某一个工作事项的时候,可以先给自己一点点的时间做一下思路的整理。找一种自己最舒服或习惯的形式去进行整理,写在电子笔记本中、用脑图整理一下、或只是一张小小的便签条,重要的是这个过程,当你熟悉了这一过程之后,脑中就会形成潜意识与肌肉记忆,每次需要沟通测试工作事宜前就会在脑子过一下思路,当然这时候什么样的形式已经不重要了。另一个其实也是在慢慢锻炼自己的自信,说话有条理且在理的人说什么别人都是愿意去聆听的,但你如果永远只是一个说话不抓重点的人,相信也无法从大部分的聆听者这边得到正面反馈。
-
尊重他人的时间:对,你没看错,尊重他人的时间。当我们有了以上三点能力的基础上,就需要在合适的时间点或时间段去准确的传递给别人你需要确认结果或探讨的信息内容。这一个比较见仁见智,虽然不是必须的,但如果可以拿捏的比较到位当然就是锦上添花了。试想你在一个比较恰当的时机去找对应的人讨论一个问题,是不是比起莽莽撞撞去找他惹人烦来的更好呢,相信沟通效率也会提升很多。当然大家也完全不需要矫枉过正,说了这个不是让你死板的去照抄的,时机和尺度的把握自己要去慢慢的练习与体会。同样的,也不是任何事都需要这样,你真的碰到十万火急的事情了,还坐在那里琢磨合适的时机?
-
收到反馈和确认:这里的反馈指的是别人针对你的沟通而给到你的答案或者反馈,我们可不能只是被动的去接受反馈,这个反馈是否正确、是否合理、是否性价比高,这些都需要我们在得到反馈后去确认一下。当然也不推荐得到反馈后立即就回复别人结果是否OK,这样会显得你太过轻率和浮躁。因为我们在沟通之前已经做了一些思路的整理与事项的准备,完全可以在得到反馈之后与我们的事前准备的预期进行一些对比与参考,从而得出的结论相信也不会像一张纸一样,一吹就倒。
3. 建立快速机制
相对于团队中的其他业务执行规范与机制,沟通与反馈这块的确是变数更大,因为团队人员不是固定的,个体的性格也是十分迥异,更不要提每天不同的情绪与状态了。所以在建立快速沟通与反馈的机制上往往需要大家根据公司业务现状与团队成员的特性来进行有针对性的制定。这里博主就简单的进行一下抛砖引玉,来告诉一些在建立时需要注意的点。
第一个重要的点就是沟通与反馈需要及时,虽然说起来很简单,但在大多数的软件研发项目的固定存在的几大阶段中,无论是任何阶段,测试团队一旦有了疑问与缺陷(当然是经过验证与讨论后的结果)就必须及时的向干系人进行沟通与确认。干过测试行业的同学应该都知道,一个缺陷发现的时间点越靠后所需的修复成本就越大。这里所需要沟通的内容不仅仅针对缺陷,之前也说了,在项目的任何阶段,只要你的论点被认可且是有利于产品质量加强与保障的,都需要及时的进行沟通反馈。我们常说的测试左移,也正好是其理念具象的一种。
另外一个就是基于我们的测试流程来开展的,相信自动化测试早已被大部分的测试团队使用与实践了起来。近几年行业中对于测试的要求也是水涨船高,在主流的敏捷开发流程中,测试如果还像以往一样拿到提测版本需要几天时间才能完成首轮的集成或黑盒测试,那对于产品的迭代更新与抢占市场是比较不利的。所以支撑我们快速反馈的另一个因素就是有完善的快速验证手段,无论是回归老模块功能还是验证新模块功能,尽早的发现问题就可以尽早的进行修复。
在快速沟通反馈的过程中,我们往往需要注意那些负面反馈,在一些研发或测试过程中出现问题在所难免,但会有部分的同学把问题本身和某些因素参杂在一起进行反馈,这样的反馈往往本身是质量不高的。所以就会出现一些跨团队或团队内部配合不畅的情况出现,这些被传达的信息也大多会被曲解。所以我们在快速沟通与反馈的过程中需要只传递正面信息,即使问题比较严重也需要做到对事不对人。
只是一味的做沟通与反馈也还是远远不够的,我们还必须关注沟通与反馈的结果是否有效。比如一件事情沟通了多次而还是没有得到解决,或者获得反馈之后同样的问题仍然还是不断的出现,这样的情况下,我们就需要与干系人一起进行下复盘,来判断是何种原因导致了此类状况的出现。因为个人的视角是有局限性的,我们需要通过团队的智慧有意识地将视角拔高,从一种俯瞰的视角来观察判断整个事情的原委。
4. 后话
纵观近几年的行业情况来看,测试团队除了在产品质量保障中的作用越来越大之外,对于团队成员自身的软硬技能要求也是在普遍的变高,同时也打造了类似与测试驱动开发的各类新颖理念。如何在团队中形成有效的快速沟通反馈机制与环境往往会在很大程度上直接拔高一个团队的整体评价。所以对于广大的测试团队来说打造各自的快速沟通与反馈机制仍然需要在日常的工作中结合自己的经验沉淀与现状,在日常的质量保障活动中进行不断的摸索与优化。
最后: 下方这份完整的软件测试视频教程已经整理上传完成,需要的朋友们可以自行领取【保证100%免费】