很多时候，说起软件的质量，我们会想到测试，特别是对于测试人员自身而言，而且从项目管理的角度，也可能会想到为什么这个问题QA没有测到。也可能是QA， Quality Assurance 这个字眼误导了大家，认为要确保质量是要尽可能的把问题在出厂（或者release）前全部找出来，虽然大家都知道这是mission impossible。

　　其实在实际的软件开发中，特别是对于质量比较重视的产品，质量的保证不只是测试，还包括了很多的其他活动，比如产品 design的group review，代码的审查等等。之前读过一些文章，很多人在提Defect prevention，而不只是defect detection。看到一篇很有趣的文章，觉得是另一种思路，很有启发。转载如下。

　　---------------------------------------------------------

　　一个伟大的应用创新：领导和工人同时下井

　　在屡屡撞破中国人心理底线的安全事故潮中，近国务院为强化安全生产，专门出了个规定：企业领导要轮流现场带班，煤矿和非煤矿山要有矿领导带班并与工人同时下井、升井。

　　相对于N多技术、制度的硬规定，这一个微小举动也许会带来更大的安全创新改革，它是一个伟大的应用创新，因为它是站在使用者的角度考虑解决问题的。

　　这个故事让我想到了另外一个的应用创新：二战时期的降落伞改革。

　　二战初期，美国空军降落伞合格率为 99.9%，这意味着每一千个有一个出事，对于这种百万级的战略性产品而言，这非常影响士气，军方要求必须达到 。

　　制造商认为产品复杂不可能达到要求。降落伞的制造工艺的确复杂，它们采取类似的设计：有一个白稠制成的半球形伞衣，它由近30个组件构成，表面积达 50多平方米。每个降落伞都有出厂编号，甚至有降落伞检验员的签名。但是，如果空降兵碰到那不幸的0.01%，他会像自由落体的物体一样坠下地面，这是空降兵的梦魇。

　　后，美军想出了一个“微小创新”：军方改变检查质量的制度，决定从厂商交货的降落伞中随机挑出一个，让厂商负责人亲自从飞机上跳下。奇迹出现了，不合格率很快降为零。

　　但是，我们的身边仍然被大量极差的用户体验所包裹，特别是我们的基础设施，一个重要的原因在于，很多决策者很少站在使用者的角度考虑问题。

　　“领导和工人同时下井”是被逼出来的解决方案，但是，只有在被逼无奈情况下才能这样吗？主动的拥抱用户体验有那么难吗？

　　-----------------------------------------------------------

　　“相对于N多技术、制度的硬规定，这一个微小举动也许会带来更大的安全创新改革，它是一个伟大的应用创新，因为它是站在使用者的角度考虑解决问题的”

　　我觉得这是一个很有趣的例子，也会让提高质量的思考更加开阔，而不只是停留在技术，特别是测试的层面。或者如有些书上提到的，build up a quality culture。不过不得不说这是一个有中国特色的方法，不知道会不会衍生出代人签到的问题。

　　是的，quality的 culture，主观的对与quality的意愿（主动或者被动的）很强烈的话，总是能够想出提高的方法，但是如果只是应付评测或者规定的条款，其得到的结果可能相差很多。

　　如此说来，不免让人有些失望，因为这样看来，QA或者Tester在保证高质量的软件的过程中的作用只是部分的。是的，我想是这样的，因为质量很多时候被很多因素决定，商业的目标和产品的市场定位，比如Benz和QQ；材料的选择，铝镁合金还是塑料（换成软件中核心的组件也是一个道理）；还有架构的设计。

　　但是尽管如此，测试在产品质量过程中还是扮演了很重要的角色，对应于上一篇中提到，测试可以保证说明书上所有的功能，包括那些不言自明的功能都被高质量的实现了，更有经验的测试人员也会验证到用户的需求和稳定性、易用性等指标，甚至往更前面影响到产品的设计。

　　总的来说，我的思路是先试图弄清楚质量包含哪些方面；然后看在哪些方面，还有方法可以保证高的质量；然后进一步来看，现在我们的测试人员做到了哪些，哪些也是我们可以去做的。这个系列的文章是这样的一些探索和思考。