独立的测试团队不需要做白盒测试

　　传统上，独立的测试团队专注于黑盒测试，而对底层的测试不屑一顾。然而，在敏捷项目中，测试人员在自动化开发测试和验收测试中扮演着非常重要的角色。敏捷测试通常是持续性的，而非阶段性的。敏捷的测试人员需要懂得设计以及了解代码层面的知识才能更有效地在一个sprint中进行测试。通常开发人员主导单元测试，而敏捷测试团队参与部分的底层测试以及主导自动化测试。

　　只有能够发现BUG的时候才能够体现测试的价值

　　测试的价值不光在于检测出多少个BUG，还在于能够保证可交付的产品的质量是足够好的。敏捷团队需要忘记从前那套以找BUG个数为上的思想。团队可能以为找到越多的BUG就证明绩效越高，结果导致了系统中记录了很多琐碎的BUG。

　　敏捷测试团队直接对产品待办列表项目的状态负责，也就是说，如果一个代办列表项没有通过测试的话就不能认为其已经完成。敏捷测试团队要多利用各种展示板来展示各个代办列表项的状态。

　　测试自动化不是必须的，而且只有在回归测试的时候才需要

　　自动化测试不是可有可无的，相反，自动化测试是非常重要的部分，尤其是需要加快一个产品推向市场的时间的时候。一个以最高速率前行的敏捷团队，会应用持续集成、自动化开发测试、自动化验收测试等工程实践。如果没有了自动化测试和工具的使用，那么团队就不能称之为敏捷团队。

　　在一个sprint中是无法进行系能测试等非功能性测试的

　　有时候，有可能无法在一个sprint中完成系统性能测试等非功能性测试。然而，这个问题可以通过在发布计划中加入一个单独的发布sprint来解决。发布sprint可以用来进行非功能性需求的测试，也可以进行一轮验收测试来验证在BUG修复后系统还能正常运行。如果有实施持续集成和自动化测试的话，那么也许就不需要严谨的集成测试了。

　　测试必须按照：计划、说明书、执行和完成的顺序进行

　　虽然计划、说明书、执行和完成都和敏捷测试息息相关，但是我们需要记住的是敏捷测试是一个持续性的过程，而不是阶段性的。例如，当一个待办列表项已经标志为完成的时候，很有可能另外一个待办列表项还处于编写说明书的阶段。有些团队会在把当前待办列表项的测试用例都用自动化实现了以后才将该项标识为“完成”。

　　不需要为已发现的BUG写新的测试用例

　　在传统上，如果测试团队在探索性测试的过程中发现了BUG，团队并不会回过头来为这个BUG创建一个新的测试用例。不这么做的一个关键原因是，改变测试文档的流程需要改变计划好的测试基准。然而，适应变化正式敏捷框架的一个基础组成部分。在敏捷测试中，如果一个BUG没有对应的测试用例，那么就要为这个BUG编写新的测试用例，然后再把新的测试用例添加到自动化测试中。

　　只要代码能够实现所需的功能，测试团队就不用计较代码的质量

　　这个观点和上面的“独立的测试团队不需要做白盒测试”是相关的。以前独立的测试团队只专注在黑盒测试，只要代码能够实现需要的功能，代码质量就不是他们所关心的问题。但是，如果测试团队能够在测试或者验证阶段就能够找到代码级别的技术债务的话，这对整个项目所带来的价值是相当可观的。这也是敏捷测试人员需要改变的关键观念之一。

　　测试流程改进模型并不适用于敏捷测试

　　实际上，我们确实有办法能够用标准的行业模式来衡量和改进敏捷测试。测试流程的改进方法，如TPI NEXT，主张在敏捷环境中利用对关键领域的优先级排序来对业务驱动的测试流程进行改进。这就是把敏捷的原理和专门的领域对应起来的敏捷测试思想。

　　结论

　　虽然，进行测试的具体方法和在瀑布式、迭代式和敏捷中在原则上没有很大的区别，但是在敏捷的思想中包含了很多新的方法另团队能够更高效地达到期望的结果。敏捷本身更多的是敏捷的实践，而不是流程。