漫画：我是程序员，总想打测试工程师怎么办？

轻友们大家好~我是珍妮兔，一只工程效率顾问。我的日常生活是和不同的软件研发团队聊天，给大家分享各种轻松把软件做好的最佳实践。如果你有特别想要解决的问题，不妨加我的个人微信：jenny1652告诉我。

---

漫画：我是程序员，总想打测试怎么办？

文|画  珍妮兔

多年前珍妮兔大学毕业，成为了一名软件开发工程师。作为一个勤劳勇敢善良的程序媛，和她过不去的，必然都是坏人，比如，

测试工程师。

那个时候有个常常在快要下班的时候跑来，说他发现了bug的测试工程师。每到这个时候，某兔的表情如下：

当然，对于有的程序员和测试工程师，最后可能会演变成这种情况：

后来，我自己成为了一名测试工程师，才意识到，其实很多人并不了解这个角色。

不了解，就会造成误解。举个例子，大学的时候，我发现有个同学她从来不吃鸡蛋。食堂里的菜里有一点点鸡蛋，她都要挑出来。当时我就觉得她可能是很挑剔的一个人吧。后来才知道，她小时候，曾经因为家里鸡蛋卖不出去，天天吃鸡蛋，吃伤了。

不了解造成的误解是这么大，今天我就给大家介绍一下测试工程师这个角色。帮助大家减轻误解，更融洽的合作。

从前段时间波音飞机坠毁事件说起。

波音737飞机因为一个软件系统的故障，在短短5个月内连着坠毁两架，两架飞机都是无一人生还。

软件缺陷造成的损失是惊人的。没那么大的缺陷，也会造成损失。我最近遇到的缺陷，是在写稿的时候，写了1个多小时的一篇文字稿，当写完最后一个句号，准备点保存的时候，电脑蓝屏了...你说你早不来晚不来。

缺陷这么讨厌，要对付它，先得了解它。

缺陷指的是下面5种情况中的至少一种：

1. 软件未达到产品说明书（就是我们通常说的spec）标明的功能。

2. 软件出现了根据产品说明书不应该出现的错误。

3. 软件功能超出产品说明书指明范围。

4. 软件未达到产品说明书虽未指出但应该实现的功能。

5. 从测试工程师的角度来看，软件难以理解、不易使用、运行缓慢，或者最终用户认为不对。

波音737的情况是哪种呢？

因为我们看不到波音737的产品说明书，也没有机会对自动驾驶系统进行测试，所以不能判断具体是1-4中的哪种。但是我们仍然可以确定这是一个缺陷，因为它满足第5条里说的“最终用户认为不对“。

5. 从测试工程师的角度来看，软件难以理解、不易使用、运行缓慢，或者最终用户认为不对。

除了最终用户之外，还有一个角色的观点至关重要，那就是——测试工程师。

测试工程师的本质，是代表用户，这个角色对软件的成败至关重要。如果一个团队没有测试，就相当于你让用户来当你的测试。如果这些问题让测试发现，没有关系，但是如果留给用户来发现，用户可能就流失了。

测试工程师上报的缺陷中，有一部分可能在后来被裁决为“设计如此”（By design)， 但这不影响测试工程师有权上报任何任何他觉得不对的问题。

所以，测试工程师哪怕上报你觉得是吹毛求疵的问题，他们也是在做正确的事情——因为这就是测试这门专业的“设计如此”。

有的时候程序员想打测试，是因为觉得测试老爱针对他们。

其实测试并没有想针对程序员，因为有时候，缺陷不是开发造成的，而是产品经理/设计人员造成的。

如果在产品设计阶段，设计的不好，导致用户体验很差，或者设计的功能本身就不完善，导致开发跟着走偏，后来测试发现了问题，也会汇报出来。所以测试人员的“找茬儿”，是在给软件“找茬儿”，并不是给人“找茬儿”

还有一种让程序员觉得不爽的情况是，测试总追着开发修缺陷。

写代码通常比修缺陷爽。写代码的时候行云流水，修缺陷的时候就没有那么顺利了。

人都喜欢先做简单的事情，把难的事情往后压。所以开发一般都喜欢先做开发，把修缺陷的工作往后压。测试人员来催的时候，开发就会觉得不高兴。

但不高兴的开发一定不知道这个图：

还是以波音737为例。如果波音这个缺陷是出在产品说明书上，并且当时有人发现了这个问题，那么修复成本几乎可以忽略不计。

如果这个缺陷在开发完成之后才发现，修复它就要改代码，成本明显升高了。

如果发现缺陷后，又等了一段时间来修复，那么这个期间，这段代码上，又会增加新的代码和新的依赖关系，甚至会引发新的缺陷，修复成本又会继续上升。

如果再晚些，等缺陷到了生产环境，修复成本最高。波音737在全球被停飞，造成的经济损失，都是在这个缺陷的修复成本里。

所以：发现缺陷了，修复越早，成本越低。当测试追着你修缺陷的时候，你要知道这是对你好。

说了半天程序员对待测试同学的正确姿势，现在也送给测试同学们两个小贴士，以便于测试同学们在做一个优秀的测试工程师同时，避免成为“全民公敌”。

第一，控制情绪。软件测试工程师真心喜欢自己的工作，当发现严重的软件缺陷的时候会容易喜不自胜。

不过，千万不要兴高采烈地冲到开发面前，告诉他你发现了一个不可救药的缺陷，因为他会不高兴的。也许你可以换下面这种说法：

上面这个是开玩笑啦，千万不要模仿，一个建议的说法是：

测试（带着虚心请教的表情）：“我遇到一个问题，能请你给看看是不是我的测试步骤出了问题？”

开发：“好呀，我看看。”

第二，不要总是汇报坏消息。当你发现某些代码没有缺陷，也要多多宣扬。多找程序员聊聊天。这样，大家就不会觉得你是坏消息的来源了。

再告诉大家一个所有团队角色都可以用的小贴士：

你们可以在团队里约定好，如果有一天你想打人，就先和对方说一句“爱你！”然后再说你想说的其他话。

这个方法也可以用在你的男朋友/女朋友身上，不信可以试试哟，不好用包退 :b

 最后把面这句话分享给大家：

---

“质量不是测试进去的，是设计/构建进去的。

质量是所有人的责任。”

---

PS: 如果你也这么认为，欢迎分享到朋友圈哟！

参考资料：

Ron Patton,《软件测试》 

陶笛漫画作品

再介绍一下我自己吧~我是珍妮兔，一只工程效率顾问。我的日常生活是给软件研发同学们分享各种轻松把软件做好的最佳实践，和把软件工程讲得通俗有趣。想跟我做朋友，可以加我的个人微信：jenny1652。不想走丢的话，请关注“轻松做软件”！（别忘了加星标哦）

科学工作，不加班

客官！在看点一下呗~