关于软件质量的思考 - 不只是测试

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

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

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

原
始出处： http://ucdchina.com/snap/7272
一个伟大的应用创新：领导和工人同时下井

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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