谁是软件质量最合适的责任人？这是一个看似有答案但好像答案又有些争议的问题。会有不少人认为软件测试人员是软件质量最合适的责任人，但当软件质量不佳时有时也会责怪开发人员。现实中，一些成熟的团队会要求软件测试人员有质量保障的专项改进，也会要求软件开发人员有质量保障的专项改进。那么有无明确性的答案呢？——我的建议是：“开发人员是质量保障的责任主体”。
我们先从人类的普遍规律来观察：从古至今各行各业质量保障的第一责任人都是创造者，而不是检查者。无论远古时期中国修建长城或城墙时每块砖上都会有构建者的签名，一旦出了质量事故，就会重点追究砖块构建者的责任。还是近代的建筑行业、硬件制造行业，一直都秉承着“质量是设计出来的”的原则，追究着构建者的第一责任。
为什么人类的普世规律中都秉承“质量是设计出来的”而不是“质量是测试出来的”？难道人们没有有把责任和压力都给测试者的情况吗？我个人相信在各行业早期也许也出现过，质量依赖检查的阶段。但后来也许发现出现了如下情况，让人们不得不重新改变了质量的责任主体。
产品的设计者和开发者因为不是质量的主体，于是只会关注进度和成本，从而在设计和构建时，会不顾及可能产生的质量风险，因而埋下了更多的质量风险。
为了发现产品构建者制造的更多的质量风险，于是加大了检查的资源投入，导致工期的总人力成本和进度都拉长了。而且为了提升产品或工程的质量，只有不断加大检查的成本资源。
因为质量风险的总数较大，导致产品质量的检查者在限定的测试资源（时间和人力物力）范围内，无法发现所有的关键质量风险，从而产品或工程会带病竣工。然后导致工程质量无法真正的得到保障。
因此，为了不增加持续增长的检查成本和提升工程质量，人们重新把质量责任主体转移到了产品设计者和开发者。
于是，产品设计者和开发者不得不在产品设计与实现阶段自发主动的去构思质量与成本平衡的方案，不得不自己仔细的检查自己的工作成果，并为了保障自己的工作成果质量自发地去学习本行业最新的工程技术和方法，以提升自己的工作效率与质量。对后世的影响则是在欧洲成长出了工程师精益求精的文化。
反之，如果产品的构建者不是质量的责任主体，那么他又何来巨大的动力来避免构建中质量风险产生的数量，他会按人之常情的去想：“我用来避免质量风险产生的时间和精力，还不如多造几块砖，这样可更多卖些钱。反正，有其他人为质量兜底。”于是乎，不但当期产品的质量风险产生了很多，更大的一个潜在负面影响是：产品构建工程师个人工作效率和技能的提升也会受到很大影响。
因为他失去了追求自己专业精益求精的动力和压力。又怎会强迫自己去多学多掌握本专业最新最好的专业知识和技能。自我学习成长方面就失去了压力，久而久之，就有沦为“糙”的工程师。
同时，因为自己埋下了很多质量风险被后期的检查环节发现，又不得不去返工修改这些质量风险，这些用于返工修复的成本对个人和组织都是没有任何价值的浪费。个人把时间浪费在返工上又进一步压缩了工程师自我学习提升的时间。在巨大的返工工作量的压力下，工程师们怎么会有耐心和精力来学习新的技能和知识从而提升自己的工作效率。
不知道读者看到这里时有无联想到，在公司中为了提高大家的专业技能和工作效率，给开发工程师们安排了新方法论的培训和提供了新的工具，但是很少能得到开发工程师们积极主动的响应。从而导致组织的效率提升和质量提升过程缓慢，似乎进度与成本成为了永不可调和的矛盾了。
如上分析所述，如果我们调整了开发工程师的工作责任就能增加他个人的学习成长压力与动力，间接减少他用于返工的时间浪费。从学习动力与学习时间两个维度上支持工程师，那么工程师们就会更主动去掌握新的专业技能和工具。从人性角度看：“任何工程师的内心深处都会希望自己的专业技能可以持续提升，从而可能获得持续提升的个人收入。”
对组织而言，让开发者成为质量的责任主体，也能打破进度与成本二选一的矛盾。这里的正向效果循环是： 产品的构建者成为质量责任主体后，产品构建过程中的质量风险减少了，后续付出的返工成本就会减少；同时，产品构建者为了保障质量，也不得不主动去学习和应用最新生产力的专业知识与工具，从而也提升了产品构建环节的生产效率。
版权声明：本文出自 架构师Jack 的51Testing软件测试博客：http://www.51testing.com/?293557
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
