“懂得如何反学习的人学得最快。”

　　                        ——作者不明

　　当QA团队和管理层刚刚开始运用敏捷的实践的时候，他们通常会遇到如何将传统的并且在他们脑海里已经根深蒂固的思想和实践忘掉的问题。

　　下面是一些从QA的角度出发，在实施敏捷实践之前需要忘却的一些关键点：

　　● 测试团队需要是独立团队，并且能够获得足够的授权才能变得高效

　　● 如果没有独立的测试策略和测试计划的话是很难进行测试管理的

　　● 在敏捷sprint中无法与用V模型

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

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

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

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

　　● 测试必须按照：计划、规格、执行和完成的顺序进行

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

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

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

　　接下来让我们来把上面的这些观点一个一个地审视一遍：

　　测试团队需要是独立团队，并且能够获得足够的授权才能变得高效

　　传统上来说，测试团队可能有以下这些组织结构：没有独立的测试团队依靠开发人员进行测试；测试人员在开发团队里面；由公司中专门的部门来进行测试——甚至可能是把测试外包出去。通常来说，测试团队希望能够直接汇报给高级项目主管，而不是报告给开发团队或者TL。他们的初衷是希望在提交BUG的时候不会被TL阻挠。

　　在敏捷思想中，测试人员必须是团队中的一员。他们应该专注的是，在没人任何技术债务的前提下，在每个sprint结束的时候交付质量过关的可交付产品，从而满足团队承诺的代办列表项的“完成”条件。测试人员要向敏捷团队汇报，而且要对PO和业务需求负责。

　　如果没有独立的测试策略和测试计划的话是很难进行测试管理的

　　通常测试策略的文档都是集团级的，公司级的或者是部门级的，至少也是产品级的。很少有人会为一个单独的项目设立测试策略，除非这个项目要持续很多年，所以为某个项目专门设立的策略通常会记录在该项目的测试计划里。

　　在敏捷项目中，测试方法可以记录在发布计划中，而针对每个sprint的测试活动应该在sprint计划会议的时候记录下来，因此很有可能不需要独立的测试计划。然而，拥有高于项目层面的测试计划是非常有用的，尤其在公司在向敏捷转型的过程中。在测试策略中，可以记录测试的实践、和在集团或者分公司中需要遵循的规则。然后，敏捷团队可以在为项目的发布计划定义的测试方法中应用其中的一些实践。

　　在敏捷sprint中无法与用V模型

　　在sprint中，验证和检查都是通过敏捷实践来实现的，例如验证需求已经按照INVEST的形式记录；编写和评审涌现的文档和简单设计；评审视图建模；举行每日站会；进行持续集成；进行代码重构；利用自动化测试进行开发测试和验收测试；增进和PO以及客户的交流。

　　下图中展示了敏捷中的V模型和传统的V模型关于验证和检查之间的区别：