需求审核
　　难道您不认为，浪费资源来交付错误的功能确实很可怕?在开始每个新开发阶段之前审核软件需求，这样做能够大限度地减少缺陷并满足客户的需求。在实现之前审核需求，这样做有助于考虑潜在的变化，克服在项目的整个寿命中可能发生的误解。团队必须与客户一起反复检查所有应实现的业务领域细节。需求审核也可以使用原型和领域模型来完成。当开发团队在开始实际实现之前完成这个小任务时，他们的项目或开发迭代会获得良好的开局。通过确保在实现之前所有利益相关者都达成共识，并且每位团队成员都意见一致，客户和管理人员可确信开发人员将在开发周期结束时交付正确的成果。
　　代码审核和演练
　　听起来像很简单，但代码审核是软件开发中有效的实践之一。它对减少缺陷数量(在错误进入软件之前在窗口中发现它)以及增强代码和软件设计的质量具有直接影响。这消除了在未来的版本中执行重大的代码重构和清理的需求。
　　依据项目需求和实现细节，团队可能认同简单的编码和设计原则。团队成员应共同遵守这些原则，而且只要开发一项新功能，一个或多个团队成员(除了作者)应审核新代码，并搜索所有编码或设计错误。
　　这种做法可在许多方面为团队带来帮助，包括提高代码质量和设计，大限度地减少缺陷，并预防它们。另外，它还使得整个团队能够深入了解彼此的工作，轻松移交工作，并提高团队对不同软件组件和功能的认知。团队协作验证和证明代码的质量和设计的实现方法。它们从同事那里获得直接反馈。这么做可谓一举两得：代码质量增加了，团队的认知和项目责任也增加了。
　　基于会议的测试
　　基于会议的测试(James Bach 发明的一种方法)表示将测试负载分解为会议，每个会议有一个任务(一种希望从测试会议获得的明确规定的结果)。每个会议有一个既定的时间范围(从 20 到 40 分钟)，测试人员在执行测试会议期间不应中断。
　　这像将测试人员放在一个测试房间一段时间，让测试人员专注于查找特定软件特性或功能的缺陷。在会议期间，测试由一组测试案例引导执行，测试人员也可以执行探索性测试。因此，基于会议的测试是正式测试方法与测试创新的一种组合，因为它提供了测试人员房间来进行探索和获得直觉思维，留出了时间和自由空间来发现不常见的缺陷，或者通过折腾软件来进一步了解它。
　　会议期间，测试人员应将软件的行为记录在案，获取快照，以及写下软件在特定输入和设置下的行为。会议结束时，将与团队领导或技术经理讨论会议脚本。从他们的讨论中，他们找出所认为的正常行为和不正常行为，然后基于讨论创建缺陷报告。
　　图 1 简短描述了基于会议的测试。对于软件中的任何新更改，计划不同的测试会议，每个会议都有一个指定的目标和任务。测试会议期间，测试人员使用测试案例和/或执行探索性测试。测试会议结束时，会报告在会议期间找到的缺陷。

图 1. 基于会议的测试工作流

　　基于风险的测试
　　因为在开发流程中进行了一些更改(主要的或次要的更改)，开发团队通常拥有同一个软件的许多常用版本。一种重要的 QA 实践是在每个主要版本之后彻底测试软件。另一方面，在每个版本中都对整个软件运行全面的回归测试既耗时又很难实现。但是，仅测试更改的功能或笨拙地删减测试案例套件是不安全的。一段代码可能解决了一个缺陷，但也可能破坏了代码中的其他内容。
　　基于风险的测试方法采用了折中方式。它的基本理念是按降序对软件功能和失败模式排序，从重要或风险高到值得拥有的功能和简单的风险(一个类似工具是 FMEA：失败模式和影响分析)。如果测试人员在严格的时间限制下测试某个新版本时手头有这个列表，他可以集中精力确保新引入的更改不会破坏其他任何内容。然后可以轻松地确保更改不会破坏软件中的任何重要的功能，因而不会发生任何严重的风险。
　　结束语
　　每家公司都希望在充满竞争的 IT 市场中飞得更高，而且在努力创造人们喜欢的软件。不幸的是，有时来自客户或不耐烦的管理层的压力可能导致团队绕开软件质量实践，终实现一个低于预期的产品。糟糕的软件质量只有在它发生故障时才会被注意到。
　　本文中讨论的实践和方法贯穿整个开发生命周期。它们涵盖需求分析、设计和开发，以及测试阶段。而且它们表明缺陷预防比在项目结束时再解决问题要简单得多，在项目结束时，更改带来的技术人情债和成本将会很高。
　　本文突出了软件质量角色和重要性，以确证忽略软件质量可能严重影响公司实现其业务目标。另外，本文还为读者介绍了一些更简单、更高效的实践，它们不但为团队节省了时间、金钱和精力，还提升了产品的质量。