摘录关于软件质量或软件质量管理方面，整整100条有价值、有启发的金句
- 1)质量是价值的体现、是公司的生存之道。
- 2)软件质量是企业生命线、产品的生命线。持续优化、持续改进。
- 3)软件质量管理是一个长期进化的历程，没有止境唯有更好，企业能走多远质量管理就有多严。
- 4)质量是一个系统工程，短时间很难看到成效，持续改进是最好的方法。
- 5)团队时刻关注质量，质量是团队中每个成员头上悬着的一把刀，持续改进深深烙在每个人心中。
- 6)没有质量保证的高速开发是一种灾难。
- 7)质量是1到100的事情。
- 8)质量免费，第一次做对成本最低。
- 9)质量不是某个人的事、某个版本的事，而是一种习惯的养成。
- 10)坚持以客户为中心，站在客户角度考虑问题。
- 11)站在最终用户/客户的角度才能衡量一个产品的质量。
- 12)检验质量的主要标准只有一个：满足使用者的实际需要，用户使用软件获得了预期的信息化带来红利。
- 13)如果质量不重要，那么在做的事情一定是不重要的。
- 14)你永远都不知道你的用户会怎样使用你的产品。
- 15)业务发展走在前面，组织架构变革要紧随其后，质量文化要根植于心。
- 16)质量是内建的，质量不是测出来的，但很多开发人员意识不够。
- 17)质量是集体内建的，缺陷的预防重于缺陷发现，这个文化还没有形成。
- 18)所有与质量有关的人都必须要有对质量的责任心，这样流程才有人遵循，规范才有人落实，质量才有人保证。
- 19)软件质量根源是开发质量，测试如何帮助提升开发质量是一个视角。
- 20)质量是一种文化，这点很重要，需要每个岗位上的人员共同加入并与自身工作融入。
- 21)流程和标准背后是企业文化，文化畸形结果自然不好。
- 22)提高质量意识，流程控制质量，避免个人能力差异。
- 23)质量不是口号，需要实质性行动。
- 24)质量文化的建设，不能只靠理论宣传，更依赖实际有效的行动，以及过程的持续把控和改进。
- 25)质量很重要，做好质量很难，需要有强领军人物和把质量重要性落到实处，而不仅仅是一句口号。
- 26)关于软件质量，始终坚持：软件质量不是测试出来的，需要对整个软件项目的整个流程进行构建，以及质量保障体系的建立。构建质量体系才是提升软件质量的核心部分。
- 27)软件质量的提升应该是全面质量管理、全员参与意识以及持续不断的价值交付效率的提升，以内部流程达到CMMI3的流程规范以及质量达到3西格玛作为年度质量目标
- 28)质量无穷尽，关注质量的同时也要关注如何低成本的实现高质量。
- 29)研发前中后三个阶段都需强调质量的重要性，软件质量是要靠全流程来保障，但现实中，不同角色对质量认知标准不一致，需要改变。
- 30)软件质量受软件生命周期中的每个细节影响，要想做好软件质量保障，必须全方位监控。
- 31)需要对软件过程有敬畏之心。
- 32)流程与人员，对质量缺一不可。
- 33)软件工程中人是万恶之源，培养人的能力与责任感，人人对自己的事负责，质量会有提升。
- 34)无论规范是否建立，软件质量还是和个人能力关系较大。
- 35)完善基础设施的情况下，以人为本，事半功倍。
- 36)流程规范严谨，开发前做好各种评估工作。
- 37)开发流程管控对质量的影响比具体细节更重要。
- 38)提倡全过程、关键环节全流程质量管理。质量管理是全员扎实做出来的，不是某方面管出来的。
- 39)还是得自上而下的支持、优化流程，提高各类人员的专业素质。
- 40)质量必须是一把手工程。一把手不把质量放在经营同等重要位置，没有办法从根本上提升软件质量。
- 41)质量问题归根结底是管理问题。
- 42)领导重视是关键，部门领导不重视质量，有再多的规范流程，也很难落地执行。
- 43)软件质量任重道远，需要领导重视、项目支持。
- 44)全员、全面、全流程、全天候质量，各个环节都要问责！
- 45)质量来源于团队整体的保证，需强调团队责任。
- 46)质量面前人人有责，质量是全公司至上而下所有人的努力的结果。
- 47)看软件的质量就先看生产它的组织，如果组织混乱，分工不清，质量肯定不行。
- 48)质量不单单是测试的事情，全员都需要有质量意识。
- 49)软件质量根本是研发质量，就像空气污染的源头是排放污染的企业，而不是监管部门。
- 50)软件质量不仅仅是测试人员的责任，应该是全员责任，这应该成为一种共识。
- 51)提测质量上不去，质量给进度让步，凡事给业务方跪舔，本身就说明了团队导向有问题。
- 52)除了建立各种规范，还得有度量，没有度量就没有改进，但也不能一味地依赖度量，可以当做一种改进的途径。
- 53)质量从需求开始，靠开发规范，测试人员保障。
- 54)需要从细节入手，不急功近利，急于求成。
- 55)开发写每一行代码都要考虑质量，提倡开发测试一体化。
- 56)质量需要有可靠的工具和有效的方法、加强规范流程来保证。
- 57)持续性的迭代质量需要一个规范的流程来保障，需要团队成员包含领导层有共同的质量意识。
- 58)软件质量是设计出来的不是测出来的，不能把所有的问题都遗留给功能测试团队去解决。
- 59)软件设计模式的选取很重要，选对了，可以节省很多时间；产品设计定位不好，累死开发、测试、交付人员。
- 60)质量由测试说了算，拍胸脯、做保证都是扯淡，见过最多的就是项目之初胸脯拍得响，后期掉链子，质量不是主观上的自信能得到的。
- 61)测试背锅的角色始终没有改变，很多行业对测试作用的理解存在误区。
- 62)测试人员可尽早介入开发设计的评审，了解设计思路，结合功能业务和设计分析会更加有针对性。
- 63)测试一定要左移，整个团队的质量意识要提高，提测后为时已晚。
- 64)面对的系统本身的特性，个性化的保证不同的方面，也是质量保证的关键。
- 65)质量意识是前提，测试基建是基础。准入准出靠测试标准，问题挖掘靠大脑。
- 66)专业的人做专业的事，不懂软件的人不要硬套方法论。
- 67)感觉公司的软件质量需要改进的地方很多，但是没有找到真正适合自己的路。
- 68)质量是构建出来的，通过人的创造力和科学的技术运用，找到适合适用自身的。
- 69)对于软件质量的评判标准还是要有一个可视化的标准。
- 70)软件质量不是测出来的，应该从源头设计开始，全员参与测试！
- 71)软件质量与开发密切相关。懂开发才更懂测试，开发和测试要共担质量。
- 72)保证软件质量是测试人员的基本素养。
- 73)通过持续测试来提升软件质量。
- 74)提升测试人员的能力，希望团队领导能更加重视和投入很多的精力在测试和质量保证这块。
- 75)渔网的好坏和池塘里有没有鱼是没有关系的，测试设计的好坏和系统中有没有bug也是没有关系的。
- 76)在低成熟度的企业里，百人规模以上应该更强调传统的QA职能，强调过程裁剪和规范。小规模和成熟度高的企业可弱化QA职能。
- 77)聚集核心业务价值，质量与效率相平衡。
- 78)软件质量是重中之重，质量就是效率。
- 79)AI未来将会起到很大作用。
- 80)在智能AI评估器到来前，这所有的一切都是人为的构建、构建、构建！只能证明哪些地方无恙，不能说明一切安好。
- 81)增强自动化客观指标体系建设。
- 82)质量在于团队协同，协同不好，再牛的人产出也低。
- 83)关于软件质量，它是一个让人头疼又非常有趣的谈之不尽的话题。
- 84)很多时候感觉自己很容易到了天花板，心力交瘁，无法入手，领导想重视但是没给力支持。
- 85)国内互联网企业竞争激烈，研发团队基本都是在做功能实现的事情，中间过程没有质量保障的活动，比如设计和代码评审、单元测试等这些最基础的质量保障活动，牺牲这些时间来追赶进度，尽快占领市场。大家都知道这是在饮鸩止渴，但项目太多、老板不断施压，很难找到走出这个困局的办法。
- 86)单元测试怎么落地，难啊！！
- 87)要质量没速度，要速度没质量。
- 88)软件最终是交付给客户的，没有用户量没有兑「现」，都是无法体现软件质量的。
- 89)因压缩资源成本，砍掉很多测试的工时，很难过。
- 90)对于重灾区的团队，吹哨人会被干掉。
- 91)公司不注重质量，只求快速出成品，测试孤独寂寞冷。
- 92)企业高层对质量认识不足、理解有偏差，业界又缺乏质量实践经验分享和支撑，质量工作很难开展。
- 93)现在产品越来越追求快，质量技能却未跟进，测试很被动，干的越来越辛苦。
- 94)敏捷开发，基础设施和服务要扎实，否则跑着跑着轮子都掉了，就别提敏捷了。
- 95)感觉好难推动各个阶段的质量把控，好多环节如需求评审，形式大于效果。
- 96)软件质量都认为重要，但在进度等压力下又容易会被忽视，人们更容易关注带来短期效益的直接指标而对改进质量带来的、缓慢的长期收益视而不见。
- 97)软件质量靠的还是整体的构建，单靠其中任何一个环节都是不行的。吐槽的地方很多，越来越快的迭代频率，越来越短的开发周期，总有更高优先级的需求插队。
- 98)体制内单位的组织改进，需要自上而下，全方位的去改。因为企业文化的原因，导致任何改变都无比艰难，牵一发而动全身。
- 99)当前规范太杂乱，国标又很多不适用，要是有专业机构来牵头规范会好点。
- 100)质量很难，测试不易，且行且珍惜。