非必要沟通对软件测试职业发展的影响

　　众所周知，沟通能力是职业发展中很重要的能力之一。根据我的工作经验，绝大部分的同事沟通都没有困难，但我们却经常在日常交流和绩效考核中提到“XXX的沟通能力需要提高”。这不是有些矛盾么？其中的关键在于”非必要沟通“。那么非必要沟通是什么意思？它对职业发展又有什么影响？本文将结合实际工作的场景来探讨这两个问题。

_W.E9B
X0　 　让我们先来看看第一个熟悉的场景。会议室里，需求分析人员在滔滔不绝地讲解需求，你在位子上洗耳恭听，一言不发。如果我说：”从这个场景来看，我觉得你 沟通能力需要提高。“你是否不同意？因为你觉得这种场合，不一定需要我发言的嘛！换到我主讲的时候，我可以把事情讲明白的啊！是的，所以前面我说”绝大部 分同事沟通没有困难“指的就是”当你主动发言或者一问一答的时候，可以比较清楚地表述自己的意思“。但是工作中更多的时候，我们不是会议的主持者或者讨论 的发起者，仅仅是参与者。此时（尤其是人多的时候）不少人常常沉默着走进会议室，又沉默着离开，”挥一挥衣袖，不带走一片云彩“。

　　这个 对你的职业发展有影响吗？当然有！首先，在讨论会上，如果你一直没有声音，别人会认为你是个没什么想法的人。慢慢地，你甚至会发现有些会议即使是需要你参 加的，人们可能都开始忘记叫你了。所以，参加讨论，无论是反对或者赞同，附和或者补充，你总该有个立场，并让与会者知道。其次，即使在其它场合你让别人感 受到你是有想法的人，唯独在会议上一般不发言，人们也会觉得你在公开场合的沟通有些问题。所以在我的测试团 队中每次来了新人，我都要求第一个月内你参加的会议都要开一次口。我只要求开口，所以即使你没有意见和建议，你也可以提问或者确认自己的理解。因为我更关 心的不是你问题的内容，而是你开口的勇气和快速融入团队的意愿。对于老同事，我们就更希望不仅仅是开口，而是有所贡献了。51Testing软件测试网^w h/v5f
MVHC

　　让我们移步换景，看看第二个熟悉的场景。开发人员在编码，你在编写设计用例。这段时间，你和开发人员经常交流么？交流些什么内容呢？根据我的观察，大部分测试人员在这个阶段会安静下来，潜心学习需求和编写测试用例，有的甚至一周都和开发人员说不上一句话。有整片时间潜心思考固然对设计测试用例很有好处，但是我认为在这个阶段进行一些看似不必要的沟通，收效更佳。这些不必要的沟通可以包括如下内容。51Testing软件测试网u:g4r.r5x

Q(c&}+`GF'q0　　（1）开发中碰到的技术困难

}g)J_5OXH0　 　开发中会碰到一些在前期没有预计到的技术困难。例如，预定方案出现了新问题而需要重新寻找方案，第三方控件出现了某个难以修复的缺陷等。这些困难会对产 品质量带来较大影响。虽然不了解这些具体的困难，我们也有可能发现某些相关的缺陷，但对于技术细节的更多了解是否可以帮助我们更有针对性地进行基于技术风 险的探索式测试呢？是否还可以帮助我们，在报告缺陷时更准确地描述缺陷产生的可能原因呢？

　　（2）开发中需求的变更51Testing软件测试网I2M!v3a}}%\

a*H%P p {1v3BMN0　 　开发中到了代码级别，可能会发现前期我们对变更的影响面分析不充分，或者由于设计和技术框架的限制而导致需求需要妥协等等。这些都会引起测试用例的更新 和测试工作量的变化。我们常碰到编码阶段开发人员和需求人员达成了某个新的结论，但忘记告诉测试人员了。如果测试人员能在此阶段及时主动地经常询问并跟进 这些变化，相信会减少误报此类缺陷的浪费。

　　（3）开发效率的变化51Testing软件测试网7\$P8_jE"WV

3Td:G$i8Fv
]o*p#?0　　即使是一个团 队，不同版本的开发效率也不一定始终如一。比如，未预计到的会议或者培训、生产环境支持、技术研究难度超出预期等都可能占用一定的编码时间。从开发阶段的 燃尽图和每日例会上反应的一些问题，测试人员可以及时地大致感受到开发效率的变化，从而评估其对后续测试工作的影响。51Testing软件测试网 O ]]L
C_

　　（4）开发中人员因素的影响

　　未预计到的员工休假甚至离职，以及因此而影响的其它任务的完成情况将对测试安排和质量带来一定影响。这种信息不一定要确切，有时即便是小道消息，也可以给我们一些及时的提醒，以便尽早作出相应的挑整。

　 　综上所述，开发进度会受到诸多因素的影响，进而影响质量状况、测试范围和测试进度。在没有开始测试执行之前，测试人员可以通过参看燃尽图，参与每日例 会，主动询问开发人员碰到的困难，倾听团队成员的抱怨，和相关的开发人员闲聊等多种渠道来了解开发的状况。如果有必要的话，还可以及时和相关人员一起商量 应对措施。这时的看似非必要的沟通往往能消除很多误解，及时跟进新的变化。51Testing软件测试网y2@)z5w{.\0Nkb

0T)l;{@cXg{\ j0　　让我们再移步换景，看看第三个熟悉的场景。新版本上了生产环 境后，系统支持人员转发了许多来自用户的Email，包括系统缺陷、使用方面的问题和希望改进的功能。对于不是系统缺陷的问题，你是否看一眼问题类别就直 接删除了？其实，缺陷固然应该受到重视，其它用户反馈的信息更值得我们去深入沟通。比如，有用户反馈他们平时习惯了只操作小键盘，所以我们系统生成的单据 号既包含英文字符又包含数字对他们而言输入很不方便。我们再和用户一沟通，发现他们每人平均一分钟要输入一票单据，所以输入的便捷性对他们而言比很多高级 功能更为重要。又如，许多用户碰到同一个使用方面的问题，虽然我们可以很快地提供支持，但这是否显示出我们前期实施培训不充分？我们是否可以回顾一下培训 的流程和材料，和相关实施人员讨论一下看此处是否可以做些改进？51Testing软件测试网Nkw,f-T

　　上述三个场景中的”非必要沟通“看似不做也没有太大的错，但实则关乎个 人长远的发展。因为测试不是孤立的活动，测试人员的价值也不仅仅是做好测试（虽然这已经并不容易）。如果我们在力争做好测试的同时，还能眼观六路、耳听八 方，不光关注自己的事情，也能关心和了解别人的事情（尤其是那些我们项目的干系人），积极主动地做好沟通，那么你的职业发展一定会有新的机会！