前言：每个人都怀有梦想或理想，测试人员也不例外，希望能将自己的工作做的尽善尽美，也梦想能构造理想化的乌托邦测试世界。
最近参加一学习论坛，知识分享后被一位年轻同行问到一个问题：你认为最理想的质量实践是怎样的？我当时的回答是：防患于未然。帮助所在组织树立正确的质量意识，共同建立并推动质量管理体系，并在产品各个过程阶段实施质量流程规范。那么，卓越的(或理想的)质量实践应该是怎样的呢？经过对行业内的优秀组织经验学习探讨，仔细思索后并针对自己多年项目测试实践分析，我依然觉着自己给出的回答是正确且合适的。
首先，质量不等于测试。质量不是测试出来的，质量是需求阶段或开发过程的问题，而不是测试问题。也就是说，卓越的质量实践是一种预防行为——防患于未然，而不是检测。优秀的质量实践组织，测试团队的目标是判断这种预防工作做的怎么样。举例一个实体企业（如汽车行业），当召回有质量问题的产品时，代价是非常巨大的。不论是汽车行业还是软件行业，如果在最开始设计创建的时候就是错的，那它永远不会变成正确的。因此，最初的方案设计和开发过程就要做正确，否则，下游将会陷入混乱的循环修复版本。
我们先看下行业内质量实践较差的组织，产品发布时，优先考虑的是功能完备性和易用性，却很少考虑质量问题。没有缺陷预防机制，工作未能平行开展及持续敏捷交付，甚至产品交付时不具有可测试性和稳定性。
甲产品a模块需求未明确，b模块需求也不完整…a、b模块需求确认后启动开发，实施中发现对整体方案设计有影响，需要重新调整方案设计及开发，项目工期受影响......
乙项目技术方案设计不是最优，开发工期紧张，还有很多其他问题要修复，先这样处理，后续再优化......
丙项目一直疲于赶工期，开发过程没时间单元自测，也没有端到端集成联调，问题点比较多，先给测试部门介入测试，等他们测试出bugs再修复......
丁产品这个c功能遗留很多缺陷，客户爸爸要求的上线时间已经delay了，先把其他功能发布上线，质量不行就再发布一个补丁包......
......
这也是为什么我们这个行业内总是布满各种有缺陷的、早产的产品。
那么，优秀的组织又是如何进行质量实践的呢？优秀的组织并不太在乎产品中是否少了一个很酷炫的功能，他们更在意产品的可靠性、稳定性和可持续交付。根据用户的活动和相关数据选择产品特性并确认优先排序。一旦产品人员对需求说明书进行更新，工作进度也会相应地更新，同时测试用例会被重新定义。所有这些工作将以最快速度敏捷交付，持续推进。测试团队更关注于质量提升和测试覆盖率的增加，始终把用户放在第一位来思考，并组织整体质量实践，除关注用户各种使用场景外，同时关注产品的可靠性、稳定性、安全性、是否符合性能期望等。质量实践过程中，各工作小组之间可平行开展工作，产品人员，开发人员与测试人员，他们对新产品需求进行确定、实现和测试，同时也对产品前一版本的错误进行更正、修改和改良。当测试人员发现缺陷时，开发人员并不是留待以后处理，而是马上进行修复，并在整个构建产品的过程中可持续进行测试。这将改善产品的稳定性，并随时交付可推出的产品，用数据指标确定里程碑完成和产品发布。
有些同学可能提出质疑，你这些都是完美流程和理论，有没有具体的优秀质量实践案例可参考呢？举例，在理想情况下，一个完美的开发过程是怎样的呢？——测试先行，质量前移。在一行代码还未真正编写前，开发人员就会思考如何测试他即将编写的代码。他会设计一些边界场景的测试用例，数据取值范围从极大到极小、导致循环语句超出限制范围的情况等，还会考虑很多其他极端情况。这些测试代码同时会作为开发工作产出代码的一部分，以代码自检或单元测试代码的形式与功能代码同时存储并开展进行。对于此种类型测试，最合适并最有效率的实施代码复查的是编写功能代码的人。开发人员的工作是实现最终用户所使用的功能代码——他们创建设计文档、选择最优的数据结构和整体结构，并且花费大量时间在代码实现与代码审核上。那么，相对应的一个完美的测试过程是怎样的呢？首先，对于人的思维方式而言，开发人员和测试人员是截然不同的。开发人员的思维模式是创建，重点考虑用户、使用场景和数据流程上；而对于测试人员，主要思路是破坏，通过写测试代码扰乱分离用户及其数据。同时，测试人员需要通过测试用例，用户场景，探索式测试，测试工具等有效手段及测试方法，从用户角度出发，验证整体质量实践并关注系统级别问题。当然，需求阶段，设计阶段也是一样。越是在产品生命周期上游阶段，更要求质量意识及缺陷预防意识更强，因为，上游遗留到下游的质量缺陷，成本及代价会愈来愈大。
虽然，质量不是被测出来的，但同样的，未经测试也不可能开发出有质量的产品。那么，当我们的组织质量实践先天不是那么优秀时，是否可以通过测试阶段或测试人员的专业检测，来弥补所有的质量缺陷呢？
产品质量实践过程有个80/20原则，也就是我们在需求分析、系统设计、代码实现阶段的复审、用例评审工作中能够发现和避免 80% 的软件缺陷，此后的系统测试能够帮助我们找出剩余缺陷中的 80% 。最后的（20%*20%）的软件缺陷可能只有在系统交付使用后用户经过大范围、长时间使用后才会曝露出来。软件测试中只能够保证尽可能多地发现软件缺陷，却无法保证能够发现所有的软件缺陷。
大家都熟知下面图中这条曲线：缺陷发现的越晚，修复的代价就越大。照这个思路来看，发现缺陷越早越好。什么时候是最早呢？一般的软件生命周期，如果能在产品需求阶段就发现所有缺陷就完美了，显然这是天方夜谭；同样的，也必不可能在测试阶段能发现所有上游阶段（需求设计、开发过程）的所有质量缺陷。
缺陷产生于软件生命周期的各个阶段，如果能在每个阶段的初期就能发现这个阶段的所有缺陷也是不错的，但这是不可能的。由于错误的关联性和缺陷的必然性，显然这不仅仅是依靠测试阶段和测试人员的卓越测试实践就能够做到，要靠团队所有人员共同努力才能提升及把控产品质量，质量意识及质量实践需在各团队小组平行推动并开展。