之前做过一次演讲：测试，从哪里来，到哪里去？
之前看到姚冬老师的文章 Quality is low 质量低是什么概念？
文章一开头也是这样一句话：
质量是什么？质量从哪儿来？质量要到哪儿去？
这是任何概念或领域的哲学三问，很难回答，但又必须回答。
今天尝试回答这三个问题。
1. 质量是什么？
之前写过《软件质量保证和管理》教材，目前在出第二版，经过多年的学习和研究，自己对质量的理解还是蛮深刻的。
简单地说，质量就是客户的满意度。
质量因客户（暂且在这里不区分客户、用户）而存在，
客户越满意，质量越高，而且可以度量——客户满意度调查。
如果细究，可以分为符合性质量、适合性质量和广义质量概念。
符合性质量算最低质量要求，即能够满足国家或行业标准、产品规范的要求。而适合性质量又进了一步，要让客户或用户满意，不仅满足标准、规范的要求，而且满足客户的其他要求，包括隐含要求。
再进一步就是广义质量（详见下面表格），既要符合、又要适合：质量是产品或服务所满足明示或暗示需求能力的特性和特征的集合。
要认识这些质量特征，就需要研究质量模型：
2. 质量从哪里来？
按照广义质量的概念，质量来自每个参与的人、来自整个产品或服务的生命周期，包括研发、运维、市场活动等，正如我们经常说的，质量不是测试测出来的，而是构建出来的（quality is built in）。所以，软件产品的质量来自需求、设计、代码、测试和运维，而且需求和设计更影响软件产品的质量。
“做正确的事”比“正确地做事”更有价值。如果需求定义错了，即做错了事情（do the wrong thing）、没有做对事情，那么以最正确地方式做事情，（设计、编程）也没有价值。就今天软件开发而言，大家越来越忽视需求工程，甚至追求不断试错、不断迭代、不断重构，是很危险的，是付出了更大的成本。如果是互联网创业中某些需求的确不清楚，社会、人性有许多未知的领域、不确定的需求，不断试错、不断迭代是需要的。但需求是比较明确的、需求是可以搞清楚的，而不愿投入精力搞清楚，那是得不偿失的，因小失大，会造成极大的浪费。
设计模式，倒是大家比较关注的，微服务、云计算、分布式架构等备受关注，注重架构的可扩展性、可伸缩性、安全性、可靠性等，但也有一些模型（包括scrum）往往忽视了设计，而之前的RUP强调以架构设计为中心，然后在实施（编程、测试等）可进行n次迭代，实际是对的（局限于当时的技术，如没有微服务架构），虽然RUP没有统一软件开发过程，甚至衰落，可以说，这也是软件工程的不幸。
软件的设计、代码，不崇尚标准，而且复用度也偏低，从而导致软件质量相对低下、资源的极大浪费，但人们习以为常。软件，今天还属于高科技、处于烧钱的时代，成本核算没有提到议事日程上来，甚至被繁忙的加班乱象所掩盖，这可以说是软件行业的另一个悲哀。追求个性、追求创新，值得提倡，但是标准化、复用，不会对个性和创新有太多的伤害。
“个性和创新”应该与“标准化和复用”达到良好的平衡。
3. 质量到哪里去？
质量的巨大价值依旧存在，不尊重质量终究会成为“不尊重自己”的一种体现。这样的例子不在少数，未来也许会更多：
……
通过技术手段提高质量，不能不说“有时是一种比较彻底的方法”，例如持续集成、自动化分析与测试、灰度发布、自动监控、日志分析与自我反馈等技术手段有利于提高质量、缓解质量问题或避免质量风险带来巨大的损失，但质量态度和质量文化更重要，许多时候，一丝不苟的工作作风、工匠精神更具价值，因为千里之堤毁于蚁穴，要做到万无一失，绝非易事。
今天软件无处不在，同时人们在物质丰富的年代更应该享受美好的生活，构建高质量的软件不仅让我们免于灾难，而且可以让我们愉悦、快乐，免于经济、健康和安全等各方面的风险。我们希望每一个软件从业人员有忧患意识、防患于未然的态度，而不是在面对灾难之后再惊醒；绝不希望在灾难之后，人们才开始对软件质量的足够重视，如同江苏许多化工企业、化工园区在两次爆炸之后才被关闭。
质量终究回归到其至高无上的地位。
