构建过程是否决定了产品的品质高低？

本文共计2415个文字，预计阅读时间需要10分钟。

今天在微博上看到几位敏捷爱好者探讨敏捷测试和质量保证的问题，我也忍不住加入讨论：Z先生：我刚看到一个大会演讲，谈到敏捷测试六大指导原则：1. 仅依赖于测试人员是不可能的。

今天在微博上看到几位敏捷爱好者探讨敏捷测试和质量保证问题，我忍不住也加入了讨论：

Z先生：我刚才看到一个大会演讲稿，谈到敏捷测试六大指导原则：1.仅靠测试人员不可能获得高质量的软件，质量是整个研发团队的责任；2. 场景是不可穷举的，测试活动必须是风险驱动的，关注于高风险的场景；3.分层自动化测试是唯一出路;4.在正确的位置进行恰当的测试是自动化的关键；

S先生：品质在于构建过程。检验贯穿构建过程，提供及时反馈。

我：什么样的构建过程才能出Unix这样的品质呢？迭代？快速反馈？TDD?

S先生：据说stroustrup听到重构时的反应是，我们从七十年代就这样做了。推荐《UNIX编程环境》，了解大师的编程方式。

我：您偷换了概念。不能说大师用了重构，C++和UNIX的品质就是靠重构或某种构建过程得来的。厨师做菜用到了勺子，不等于菜好吃是因为勺子。

S先生：我没有概念。我们看到一个果，就问因是什么。其实是泛因果，无因果，一切是机缘凑巧。

我：“品质在于构建过程”难道不是一个明白的因果描述吗？

S先生：品质在于构建的人。我说话时没因果，你看到了因果。

我：欢迎敏捷爱好者围观！

很高兴几个回合讨论下来S先生修正了先前“品质在于构建过程”的观点。什么重构、TDD、迭代、快速反馈等等构建过程都不是Unix品质的核心要素。我不但不认同“品质在于构建过程”、“测试是最好的设计方法”这类机械式的观点，而且也不满意把软件优劣归结于“人是根本”的简单回答。