测试别被敏捷忽悠

这篇帖子原先发表我在博客园的blog里，还有一些讨论，想想还是在这里也发一份吧。这个应该是几个月前的事情了。

       个人对敏捷一直很关注，其实很正常的啦，作为一个资料的深度收集爱好者，在满眼都是敏捷的今天，想不关注都不可能啊。

        腾讯无线研发部副总监张鼎(dylan)写了一篇《反思：别被敏捷忽悠》，里面的观点我个人很喜欢。这个应该是对dylan的访谈整理，也许会和dylan的意思有偏差，但假设不是记者太无良，dylan的思想应该是反敏捷的，至少对敏捷思想有很多的质疑。

      提炼一下dylan的观点：

1. 敏捷方法会拉低质量标准。
2. 传统瀑布和敏捷方法没有本质差别。
3. 互联网软件和传统应用型软件开发没有本质差别
4. 在一些情况下，文档优于沟通。

      上面的观点是我总结的，具体内容大家可以看原文，有误读的地方请原文作者谅解。

      其实对于敏捷，我的观点一直很矛盾，对开发人员这应该是好的，但是对于测试则未必。

      敏捷从根本讲应该是开发方法，不是方法论，所以很多人可以把敏捷嵌入到CMMI、RUP等开发流程框架内。换句话说，敏捷说了开发人员应该怎么做，但是没有说比如测试人员做什么，也就是说，无论XP还是Scrum等，基本都没有考虑测试人员在其中应该做什么。当然了，有些开发人员会说，还要测试人员做什么，有TDD、BDD等，测试人员滚一边去玩吧。但是测试人员真的可以缺席吗？

      测试人员其实一直努力的在希望嵌入到敏捷开发过程中，比如段念的《什么是敏捷软件测试》，朱少民的《究竟什么是敏捷测试》等，甚至有专门的书籍说敏捷过程中的测试，但都像是CMM的效颦TMM一样，没有太多的信服力。感觉就是在敏捷过程中，强加了一个测试角色，做和传统测试差不多的活儿，看上去很美，但是总觉得相当的不协调。

      测试是什么，测试是质量的控制和度量。就和帖子最开始的dylan说的一样，敏捷实际在降低质量基线。敏捷的说法是从根源上，通过TDD、BDD、用户现场确认等方法，解决质量确认问题。认为通过用户认证了，就是好的。但是用户不是专业的测试人员，对质量等的认知，其实是有一定偏差的，敏捷方法貌似总在有意无意的忽视这种质量偏差。

      在软件工程中，有一个基本的观点，不要让开发人员测试自己的程序，但是在敏捷过程中，测试角色是大部分由开发人员直接兼任，当然带包装的--测试驱动开发，但实质还是开发自己负责自己部分的质量问题。产品的生产者是开发，质量的提供者是开发，难道质量的确认者仍然是开发？或者再加上用户？这样做是否会出问题？

      从根本说，敏捷方法的研发者都是开发出身，对测试我想未必有深入的了解，敏捷方法其实规定的都是开发人员的行为，但是问题就在于没有留出测试验证的位置， 测试人员即使挤进去，也有很多的力气无法使用上。比如敏捷测试过快，是否有必要重复的做开发人员做过的测试；敏捷变更太多，测试人员能否跟上变更的节奏等等。

      我这里仅仅是提出问题，并没有解决问题。敏捷开发我还是仅从大家的资料中了解分析，测试也更多从理论和别人的文章中获取敏捷测试相关内容，也许我的整篇文章观点都是错误的，但是至少希望能给测试人员以思考，至少能提出一个让我认为合理的、可以容易确认执行的敏捷中的测试过程，也就不枉我打这么多的字了。