软件敏捷测试是否写测试用例(4)

　　LoveTT ： 一看你就是科班出身，是做质量管理的吧!

　　什么事情都看得这个规矩，我觉得规矩没有错，但是规矩制约了发展就是错误了，你所谓的评审，审核，在一般的测试过程中是没有问题的，而在敏捷测试过程中，他的测试团队覆盖面很广，可以快速的识别问题并且修改问题，要是等待你的评审恐怕黄花菜都凉了!

　　魅力彩虹 ： 楼上LOVETT的观点我不同意，你老说这个教条，那个是平时的工作，不是做敏捷测试。那请问一下你做过敏捷测试吗?你的观点依据又是什么呢?

　　LoveTT ： 根据我这个测试新手孜孜不倦的学习，倒是接触过一些，记得前几天IBM刚开了一个什么大会好像这个论坛中也有报道，我演戏了他的整个敏捷开发的过程，以及他的质量控制方法，所以我以此为依据说出上述论断，大家要是有争议，可以看IBM关于敏捷开发的文章

　　魅力彩虹 ： 评审用例不仅是规矩的问题，用例不去评审就盲目的执行，怎样保证执行的正确性?发现了BUG怎样反应给开发人员?有些用例你认为覆盖了需求，你有怎样知道自己执行的用例真正体现了需求的定义?如果根据个人临时在大脑中想到的用例来测试系统，测试的有效性和以体现

　　LoveTT ： 《Agile Testing - What is it? Can it work?》和《Agile Testing Challenges》

　　大家可以看一下这个两本书!

　　所以我觉得敏捷测试有没有设计测试用例，要不要评审，这个是两个概念，楼上的跑题了

　　傲气凌云 ： 但是在你工作中，你可以这么做吗?即便是公司就你一个测试人员，也是需要编写测试用例的。同样，也就伴随着评审等一系列活动。

　　shinnoshi ： 敏捷是少文档，少流程，多沟通，使开发与测试更加紧密。不是不需要文档，不需要流程，不需要测试用例。

　　请问你提及的测试通过，开发完毕是用什么来衡量的?

　　ash ： 敏捷的不是反文档的。

　　测试用例最终生成也会以文档数据方式存在，并且是显性知识，是可以传播、共享和继承的。(不清楚看下面解释)

　　我们应该清楚文档的本质是把知识显性化。在一个项目中存在很多需要沟通的知识，知识具备两种形态，显性的和隐性的，传统的观念是尽量把隐性知识显性化，即文档化，而忽略了这其中的代价(特别是更新同步文档的代价)。

　　因此，在实施敏捷的时候，需要在团队内明确哪些知识是必须显性的，这些知识可以通过文档交流。哪些知识是可以隐性的，这些知识则完全可以通过口头的方式进行交流，以达到沟通的最佳效率。

　　new.bug ： 个人觉得，敏捷测试只是相对而言的，比如让你测试一个比较复杂的系统，功能很多，那你说不用测试用例怎么比较有条理的进行测试?

原文转自：http://www.uml.org.cn/Test/20112235.asp