最近随着敏捷测试在中国测试届风起云涌，其中包括不少公开课以及各种文章和在线分享，越来越多的人开始关注敏捷测试和敏捷开发。不过仍然有不少人对敏捷测试和敏捷开发提出了质疑，其中最典型的就是：

  • 敏捷测试和敏捷开发只适合小型项目玩一下，不适合大项目，因为一般大型项目质量要求非常高，敏捷做不到高质量
  • 敏捷开发没有完备的文档，难以维护，质量难以维系
  • 敏捷测试没有完整的测试用例，很难进行全回归测试，无法保证质量

理论上同样的团队在单位时间内获得的质量，瀑布要比敏捷高。但是这里有几个前提常常被人忽略，那就是软件需求必须一开始就能确定并且能分析和设计得十分清楚，其次开发过程中不能有大的变动，最后不需要频繁发布。如果在满足这三个前提条件的情况下，相同团队在相同时间内通过瀑布模式开发出来的软件的质量应该比通过敏捷开发出来的软件质量更高。

但是就是这种高质量的开发模式在上个世纪70，80年代遇到了巨大的问题-软件危机。当时由于软件规模越来越大，导致很多大型软件延期并增加大量预算，或者开发出来问题很多而无法使用。也许很多人会说是因为当时使用的技术不够成熟和完善，当时的软件工程管理问题或者当时的人能力不足原因造成的。但通过分析当年软件危机的案例，我发现这些危机主要有以下原因：

  • 由于软件过于复杂，无法在开始分析并设计好，需要在一边做的时候一边修改设计
  • 客户或者业务人员不知道或者无法确认业务需求细节
  • 开发过程中出现大量需求更改，导致很多完成的功能需要修改
  • 由于测试滞后，如果测试用例太多并且bug也比较多的情况下，会导致回归测试需要的时间太长和导致交付周期变长

瀑布

在瀑布模型中，有非常严格的变更管理，所以如果设计过程中有不少没有想清楚的需求，就有可能造成开发过程中有不少业务的更改，从而导致很难在预算内完成计划功能，或者导致无法在计划时间内完成全回归测试，并产生了软件危机。

所以瀑布模型并不是无法控制软件质量，而是无法在应对较多变化和未知的同时又能在有限的时间内控制好质量。如果在没有大量变化和未知的情况下它比敏捷能更好地控制质量。

敏捷

敏捷开发是为了解决瀑布模型不能很好地应对变化，并产生软件危机的问题。由于敏捷方法论里面假设没有人能在一开始就想清楚整个业务需求并完成设计，而是将这个业务需求分成一个个故事，并在做的过程中逐步完成分析，开发和测试工作，从而更有效地应对需求的变化。由于测试也主要是针对故事卡的，并且需要大量自动化来支持持续集成和持续交付，所以如果自动化测试的覆盖率不高，那么敏捷开发的质量就很难以控制。

总结

瀑布和敏捷两种模型都可以获得高质量的软件，只是前提和适用的场景不一样。

瀑布适合需求清晰，并且开发过程中没有或者少量需求变化，并且回归测试之后bug数量少等场景下才能在有限的时间内有效的控制软件质量。

敏捷适合需求开始不清晰，或者开发过程中需求不断变化，并且自动化测试覆盖率需要很高的场景下面才能有效地控制软件质量。

因此对于越小型的软件，使用敏捷还是瀑布对于质量的控制差别不大。不过对于越大型项目，在相同时间和相同资源的情况下，如果在开发过程中需求变化越少，瀑布对于质量的控制越好，反之则是敏捷对于质量的控制越好。