沟通的发现

从某种程度上说&＃xff0c;技术类工作的严谨性决定了工作内容相对枯燥。我相信&＃xff0c;很多测试人员也和我一样对这一点深有体会。然而在最近参与的两个项目测试工作中&＃xff0c;我发现轻松沟通让工作变得不再那么枯燥。



举最近几次填写缺陷跟踪为例。我们都知道对于开发修复的bug&＃xff0c;需要开发人员添加评注&＃xff0c;描述问题产生的原因等信息。长期以来&＃xff0c;大家都以正式的语言进行描 述&＃xff0c;但是有趣的是&＃xff0c;在最近发现的一些bug中&＃xff0c;有几名开发人员都是以诙谐的口吻描述问题产生的原因&＃xff0c;让工作变得生动起来。我们知道测试人员验证bug本身 就是一项重复性工组&＃xff0c;因此开发人员的这种做法大大降低了这一过程的枯燥&＃xff0c;很好的鼓励测试人员。就拿一个没有过滤html代码导致页面样式乱掉的问题来说&＃xff0c; 开发人员的评注内容如下“输入恶意代码的小二应该吊起来摸”。这样幽默的说法既让我们了解到了bug的原因&＃xff0c;又润滑了开发和测试人员之间的关系。其功效不 可说不大。



此外&＃xff0c;测试人员可能会遇到一个开发标注了已修复的bug在验证时发现问题并未修复好的情况&＃xff0c;这个时候对于测试人员往往会觉得有些沮丧&＃xff0c;尤其当问题多次反复 时&＃xff0c;可是换位想想当开发人员看到bug被重新打开时的心情&＃xff0c;这个时候开发和测试之间就会形成一种微妙的“紧张”关系。但是当测试人员以幽默的口吻加以评注 的时候&＃xff0c;我相信情况又会大为不同。以我遇到的一个问题为例&＃xff0c;我在评注里写道&＃xff1a;被忽悠了&＃xff0c;问题明明还在嘛~~.当这条bug再次被开发置为已修复状态时&＃xff0c;我 看到评注里他的描述是&＃xff1a;严重郁闷&＃xff0c;我本地环境都OK&＃xff0c;要不你再看看&＃xff1f;



可以看到&＃xff0c;这些生活化的语言&＃xff0c;从某种程度上拉近了开发和测试之间的关系。也缓解了工作的疲劳&＃xff0c;当然描述清楚问题、解决问题、避免问题的再次发生永远都是缺陷的灵魂&＃xff0c;但是能不能给这个灵魂一个亲切的外表还是需要测试、开发的共同的修炼和努力。