【鸟事儿】BUG是程序与QA之间的一场宿命之争
一篇好文章会让你不知不觉就读到最后一句话，并感叹同样头顶一片蓝天为啥作者就能写出这样一篇好文；而一篇烂文章则会通篇引经据典，给你讲各种大道理，实际读完却发现没啥卵用。
这篇《When someone gives you a bug》显然属于前者，作者RobotJoe，在全文没有使用一句专业术语的情况下，以修电灯作比喻讲述了他的一次Debug的经历。表现手法之精妙，文字之精彩，堪称技术型写手的典范。我看到这篇文章，是因为它的中文译文被技术大牛池建强整理并分享到了公众号MACTALK中。
今天Bird就在【鸟事儿】这个栏目中把故事分享给大家。
如果你有好玩的开发或测试方面的故事，欢迎分享给Bird。我会挑选好的故事在【鸟事儿】这个栏目中分享，此外，一旦选中，你就能获得价值50~1000元不等的分享基金。
有人向你反馈了一个 bug，然后故事就发生了……
「26 楼会议室的灯亮着。得把它关了」。bug 的备注里写着「你应该能在 5 分钟内搞定，只要按一下开关就好了」。于是你去了 26 楼的会议室。灯的确亮着，但房间里没有灯的开关。
你准备安装一个开关。设计师说，开关会破坏房间的美感，另外，墙壁是混凝土，你需要专业的工具才能安装开关。没有人会批准这样一笔预算。没有合适的工具，安装开关将需要两天时间，但是他们希望你现在就能把灯关上。如果 CEO 心血来潮去 26 楼逛逛，并恰好路过了这间会议室，问为什么灯是亮着的，就糟了。
于是你不断地收到各个部门的邮件，询问为什么会议室的灯还是亮着。现在你不得不群发一封邮件说明情况，灯亮着，没开关，没工具安装开关需要两天。这个信息让邮件里的人们充满恐慌，大家开始游来游去的讨论，结论是，26 楼会议室的灯亮着，你得马上把它关了。
你知道，如果这么讨论下去，这个问题永远也不会得到修复。bug 系统里，这个 bug 归你所有，它的最后期限就是今天。如果问题没有解决，你就麻烦了。所以，你设法进入了 26 楼走廊的天花板，找到了会议室灯的电线，一刀两断。问题解决了。
你发了一封邮件，说明了你是如何解决问题的。
邮箱安静了一阵。第二天早晨邮箱又开始不停的响起来，因为会议室里的灯既无法开启，也无法关闭。如果 CEO 想在那里开会怎么办？因此，他们要求你「把灯的电线牵引到地下室去」。当有人需要开关灯时，他们会通知你到地下室去，连接或断开电线。
你抗议这个荒谬的解决方案。你的上司说，「是的，我知道这不理想。但它是现在唯一的解决方案」。
这时，你面临着选择。你可以照着他们说的做，或者辞职以示抗议，另谋高就。但你知道，一旦你开始了新的工作，新的「他们」很可能也会要求你做这么白痴的事，嗯，也许是更白痴的事。
你把 26 楼的电线引到了地下室。当你进入地下室后，发现已经有几十条电线挂在墙上，你知道你不是一个人在战斗，也知道了这个白痴想法是从哪来的。你调整好了电线，尽可能友好地贴上标记，默默地向下一个可能处理它的哥们道歉。
终于，你回到了你的办公桌，准备喝杯茶喘口气，读读 MacTalk 的文章。这时候你收到了一个新的 report。 QA 重新开启了 bug。
bug 描述里说「房间还是亮的」。
你回到 26 楼的会议室。灯是灭着的。你返回办公桌前，关闭了 bug，注明你已经亲自检查过了。
QA 再次重新开启了 bug。bug 描述里坚持「房间还是亮的」。你再次亲眼确认了灯泡是灭着后，你将情况汇报给了上司。他建议你去地下室检查电线。你抗议说你正直勾勾地盯着灯看，它就是灭着的。
「我知道，但去检查一下。这样一来你就可以告诉 QA 你确认了所有流程」。你的上司说。
你叹了口气，前往地下室。果然，电线没有连接，切口两端都好好地被包裹着。它们不可能以任何你能理解的方式导电。你向 QA 反馈，你检查了电线，它们没有连接着，你正看着灯泡，它是熄灭的。
「我不是指灯泡，」QA 说。「bug 里描述的是房间里的光线。房间现在仍然不够暗。你应该拉下百叶窗」。你忍住杀人的冲动回应说，百叶窗不归你管，bug 描述的是灯光。QA 不相信你，发出一组电子邮件，询问 bug 是否包含百叶窗拉下的问题。
你默默等待了一会，邮箱又一次响起来。
「从理论上说」，他们问，「如果光太亮或太暗的话，在 26 楼会议室开会的人能自由拉上或拉下百叶窗吗」？
「是的，他们可以」，你回复。
「任何一个普通人都能做到吗？他们就不需要你做了吗」？
「是的，任何人都可以做到这一点」。
「太好了。那么，灯光问题暂时到此为止吧。我会安排如何处理百叶窗的会议」。
bug 被关闭了。现在，CEO，可能知道了一些关于 26 楼会议室的讨论，他感觉到了什么，于是希望在那里开会。你收到了几封希望开灯的惊慌失措的邮件。你去了地下室，连上电线，并返回办公桌。这期间你发现你的收件箱多了 32 个新消息。「出问题了，灯还是熄灭的」「有个问题，还是没有灯光」 「你收到我们发的邮件了吗」……等等等等。
第 32 封邮件说道:「没事了，灯亮了」。
你默默合上电脑，准备回家享受一下阅读和安宁。如果要说今天有什么好消息的话，那就是在会议结束后，大家甚至都忘记了 26 楼有个会议室，你也不需要对它做任何处理。
为什么我会把标题写成BUG是程序与QA之间的一场宿命之争？
其实在工作中，不论是程序还是QA，大家都是希望把工作做好的。只是解决问题的过程并非一蹴而就，在资源有限的情况下，很多问题程序员没有办法完美解决。QA也有苦衷，因为他们的责任正是要让用户体验到一款各方面表现近乎完美的产品。
故事的最后，作者用了一个不完美的办法暂时处理了BUG，却在他自己心里留下了一个遗憾。显然他自己也不喜欢这样一个千疮百孔，又挂着各式怪异补丁的程序。对于作者来说，如果有办法提高他Debug的效率的话，情况将会有所不同。
我想TestBird正好能够帮到他，比如我们可以快速在几百台手机上自动进行APP的兼容性测试，测试之后能够输出详尽的测试报告，他通过日志和截图就能定位问题。而我们的云手机也能帮助到他，这里有2000多台真实设备，能够方便开发者进行远程真机调试。善用这些工具，BUG可以被更快修复，时间也会变得更加充足。