一个笑话，测试驱动的重要性

有这么一个笑话（转）：

1. 程序员写出自认为没有Bug的代码。
2. 软件测试，发现了20个Bug。　
3. 程序员修改了10个Bug，并告诉测试组另外10个不是Bug。
4. 测试组发现其中5个改动根本无法工作，同时又发现了15个新Bug。　
5. 重复3次步骤3和步骤4。
6. 鉴于市场方面的压力，为了配合当初制定的过分乐观的发布时间表，产品终于上市了。　
7. 用户发现了137个新Bug。
8. 已经领了项目奖金的程序员不知跑到哪里去了。
9. 新组建的项目组修正了差不多全部137个Bug，但又发现了456个新Bug。　
10. 最初那个程序员从斐济给饱受拖欠工资之苦的测试组寄来了一张明信片。整个测试组集体辞职。　
11. 公司被竞争对手恶意收购。收购时，软件的最终版本包含783个Bug。
12. 新CEO走马上任。公司雇了一名新程序员重写该软件。
13. 程序员写出自认为没有Bug的代码。

怎么样？这个笑话是否博得您会心一笑、心照不宣呢？在这个玩笑似的例子中，一切都是以开发工作在驱动，这首先就是一个方向性错误。产品最终是要为用户服务的，当然应该是以用户和市场作为驱动，并且结合自身的能力最终确定工作的重点。这一错误折射出项目管理者对被管理的内容很不了解，只好任由比较了解的程序员摆布——事实上，他们除了技术，并不会了解更多。

其次是质量把关。基本的质量管理常识告诉我们，每次循环结束前，最重的工作就是总结改进。只有这样才能保证循环运作是向上发展，而不是失去控制地向下发展。也只有有效的测试和质量管理，才能保证迭代过程是收敛发展，并最终达到目标。但在上述例子中，这个部分显然是低效的。

而后是人力资源管理。软件开发是一项劳动密集型的工作，虽然这是脑力劳动的密集，但同样意味着人为因素在其中占有决定性的地位。例子中未能改完BUG的程序员拿到了项目奖金，而同样辛苦工作的测试人员却低人一等，被拖欠薪资，表现出管理者对他们的工作内容毫不了解，以及对软件质量管理的极不重视。这是一种谋杀团队的行为——谋杀一个团队远比建设一个要容易得多。

来源：转自新职的电邮