质量是设计出来的，还是测试出来的？

一个有意思的讨论

“质量是设计出来的，还是测试出来的？”

可能在我刚从事软件测试的时候，就被问到过这个问题；最近我突发奇想，也把这个问题提给了我的团队，我想看看大家是怎么想的。

针对“质量之道”的本源之争，大家的发言很踊跃，我摘抄了几个具有代表性的：

A同学：我认为质量是设计出来的，在设计上考虑的各种非功能质量数据，都会落地到代码中。设计的优化会不断的驱动系统质量的优化。
（A同学说完后，现场响起了一片掌声）

B同学：我认为质量是测试出来的，设计的东西可以避免已知的问题，但在实际测试的过程中，还是会发现其他未考虑到的问题，例如兼容性问题，你能提前通过设计预防吗？所以测试发现问题，问题驱动质量提升。
（B同学说完后，现场响起了更热烈的掌声）

C同学：听完B同学的发言，我更坚信了质量是设计出来的。在不断的BUG驱动下，我们打补丁式做出来的系统，质量会更好吗？打补丁解一时之急，而后续系统性的设计、重构、升级，才是提升质量的关键点。所以...
（C同学话还没说完，就被热烈的掌声打断）

D同学：如果站到产品层面，我们会怎样去定义产品好不好？在我们定义产品好坏的质量模型里，很可能会包含软件研发相关的非功能质量属性(ISO9126)，可能会包括产品舆情、竞品对比中挖掘出的东西。例如，我们去定义一款内容推荐产品的好坏，除了“内容不重复”、“多样性”等维度外，“是否支持分享”、“是否支持点赞”也会成为质量好坏的评判标准，新功能上线、满足需求，用户就会认为产品好。我们的认知会不断升级，“好”的标准也会有更高的要求。用户无时无刻不在使用、测试、反馈，让质量不断变好。

既要、又要、还要、且要

上述的四位同学的观点，代表了不同的质量理念和追求：

1. 谋而后动的观点：无论是对需求的二义性分析、对设计中UML图的流程分析、时序分析、状态分析，都是希望能够磨刀不误砍柴工、降低成本。A同学说得对。
2. 探索式测试的观点：无论是保证在设计变成代码的过程中是否100%的完成翻译，还是在测试的过程中受到启发认为应该写下更多的逻辑代码，都是希望所见即所得，想人之未想。B同学说得也对。
3. 技术债的观点：无论是对前段时间的补丁代码进行重构，还是对系统进行架构的升级，还是对基建能力进行优化，都是希望能够打好底盘，走的更远，走得更稳。C同学靠谱。
4. 持续改进的观点：无论是做竞品分析、舆情分析、线上主动检测、监控、产品质量模型等事情，都希望能够在已有认知和未有认知里发现问题、发现不足。D同学思维广。

既然大家都说得对，都代表了一种优秀的质量理念，那么就不需要取舍了，既要、又要、还要、且要。

所以我们最后的结论貌似就成了：

“质量既是设计出来的，也是测试出来的，还是被逼出来的”

：）

比结论更有意义的是什么

无论在工作、生活还是对道的追求过程中，我们常常会面临这样所谓的终极拷问：

质量是设计出来的，还是测试出来的？

面对这样的终极拷问，进行思考、讨论，并不是为了比出谁优谁劣，而是为了让大家辩证的看待问题，找到其他理念的优点，提升自己的认知。

广开言路、海纳百川，思辨让思维更自由。