敏捷方法已经获得了越来越广泛的应用。这是很容易理解的，特别是从开发人员与用户的角度来看。
1. 用户——系统的需求与过程上的细节问题似乎永远也问不完，然后还要仔细阅读大量的说明文档，而他们明白这些文档会成为将来法庭上的证据。
2. 开发人员——需要严格地遵循说明文档而无法表达自己的想法或发挥创造性天赋。他们知道即使有更好的办法，他们也不能更改说明文档，否则这就会成为将来法庭上的证据。
但是对于质量保证人员来说，敏捷方法却会带来麻烦——在原来的理想情况下，他们只需要用既有的说明文档来验证"完成"的产品。要根据一个变化的背景验证一个活动的目标是很不直观的。这表示所使用的技术与自动化也更复杂，并且需要一个新的测试方式，一种类似于用户和开发人员之间的关系的方式。
所有的敏捷方法都有（至少）一个共同的特征，那就是对QA职业的影响。如果所谓的影响是质量上的一次大飞跃，那倒也不是什么坏事。但是，如果决策是根据无效的范例做出的，改变就不一定能与过程同步了。对于开发人员来说，新提出的软件开发范例以开发人员为中心可能是很平常的事。Abraham Maslow曾经说过："擅长用锤子的人喜欢从钉子的角度考虑问题。"但是作为质量保证人员，我们不能装作敏捷开发不存在的样子，我们必须保证那些拿着锤子的人不会去硬敲一颗螺丝。
某些人可能会对QA提出怀疑，认为测试驱动开发（TDD）才是测试的关键。但是，伴随着需求和方案的发展，QA在整个过程中都是与敏捷小组直接发生联系的，是整个测试设计团队不可或缺的一部分。但这只是QA团队所面临所必须解决的众多误会中比较表面的一个。
对测试的误解
最近看了网络上所谓专家写的文章，发现了一些对TDD与QA部门的误解。本文将解释部分误区，并集中讨论QA团队要在敏捷的世界里获得成功所必须解决的一些问题。
1． "你只需要做单元测试——TDD测试已经足够"
对于大部分商业开发来说，根本就没有这回事。即使是敏捷开发的强力拥护者也承认他们需要一系列的测试技术。
TDD程序设计人员需要这些测试来验证代码的正确性。如果需求（测试用例）解释错误，那么你构建的代码也将无法达到目标要求。
大多敏捷项目都会使用探索性测试方法（黑盒）来支持白盒测试，而不会认为这两种技术只能选一。优秀的探索性测试可以在开发地过于深入之前发现开发人员所忽略的问题。
2． "你可以重用单元测试来创建回归测试集"
有些TDD拥护者认为常规的下游测试（downstream testing）是多余的，因为每一行应用代码都有对应的测试用例；他们认为重用单元测试就可以做到用户验收测试和回归测试所能做到的一切。
这听起来挺有道理，但由于某些原因，这是不现实的：TDD中的白盒单元测试的粒度与目标与下游黑盒测试的目的是不同的。
虽然单元测试的整体目标是保证代码能够实现所需的功能，但是回归测试的目标是保证被改动的应用代码不会产生意料外的效果。这两个目标是不同的--比如，检查一项属性是否具有合法的日期格式，与检查输入域中是否存在所需的日期是不同的。单元测试工具
文章来源于领测软件测试网 https://www.ltesting.net/
