对于来自客户方的软件需求，我们直观的感受都会理解为，对一系列功能的期待。而软件构建，无非就是实现这一系列功能的过程而已。但事实是，总会因为经验和粗心的原因，我们会被此起彼伏的缺陷搞得心烦意乱。
其实只是因为客户很少会把质量当做默认的需求提出来。而我们也并未给自己一个机会，在软件构建中，明确质量的范畴到底意味着什么？对功能诉求恰如其分的满足当然是，对非功能（更合适的叫法应该是跨功能）需求的实现当然也是，还有缺陷的数目要足够少，代码的质量也要足够高。还有更多。
所以质量的范畴，远比我们想象的要广阔得多。有经验的开发者，在软件开发的初期，对显性的需求始终有谨慎的态度。因为他知道在繁杂的功能背后，需要填补进多少努力，才能保障理所当然的质量。以及我们知道，发现缺陷和问题越晚，修复的成本越高，所以如果只是期待测试人员作为守门人承担这努力的职责，也就必然是不现实的妄想了。这便是质量内建的初衷了。
质量内建是敏捷测试的核心，需要将测试全程介入、团队为质量负责和持续精准的自动化测试结合起来，在敏捷软件生命周期的每个环节做好缺陷的预防，把质量融入到产品的开发构建中。
曾经有国内传统行业的IT管理人员，质疑“团队为质量负责”这句话，认为有人为反正会有团队为质量负责，自己要不要负责并不重要，所以应该改成“我为质量负责”。企业文化对于人的思维的影响可见一斑。责任事大，所以只看到了负责两个字，而没有看到团队两个字。
当然这不只是喊喊口号就得以顺利进行，我们需要具体入微的流程和方法，去实现所谓的团队负责。比如：
- 测试人员和业务人员共同参与需求的分析，切分以合适的粒度，不止是功能范围，还有可测试性，可集成性等多方面的考虑。
- 测试案例先行于开发实现，验收条件清晰，Desk Check全角色参与。
- 开发人员选择合理的方案实现，自动化测试精确覆盖。持续集成七步提交。
- 精准回归测试，以及对生产环境监控。
事实上，对它们一一列举是徒劳的。因为整个开发活动中，每一个动作都点滴集聚对于质量的影响。高质量的反馈，必然需要团队全员在流程上，以及诸多实践方式，尽可能严丝合缝的协作。
有了如此极致而理想化的期待，我们自然就对参差不齐的质量问题见怪不怪了。
