|
对于敏捷 测试 ，可定义如下：项目中使用敏捷技术的相关测试实践， 开发 作为测试的顾客，强调测试先行的设计理念。在敏捷 开发 中，测试被整合到整个开发的生命周期中。 club.mypm.net
敏捷将被越来越多的人所接受，这很容易理解，如果从开发者和用户的角度去看的话。PgMp.mypm.net
对于用户，他们不愿意花费大量的时间被人盘问关于整个系统的 需求和过程，而且需要评审大量的规格说明，而且开发团队可能会在后期拿着这些规格说明来与他们"对质"。bbs.mypm.net
对于开发人员，他们希望发挥自己的想象空间和创意，不愿意遵循规格说明的约束，尤其是在他们看到有更好的解决方案的时候。项目管理者联盟
 pmp.mypm.net
然而，对于QA人员来说，敏捷意味着什么呢?敏捷会给他们带来诸多不便。在理想的世界里，他们会获取一个"已完成"的产品来针对规格说明进行验证。现实中，他们被要求对"正在移动"的目标进行验证，这是违背直觉的。这意味着一些技术和 自动化的使用变得困难，需要新的测试方式。项目管理论坛
所有敏捷方法都有一个共同点，就是它们对QA角色造成影响。service.mypm.net
随着TDD(Test Driven Development)的出现，有人开始质疑QA存在的必要性(既然TDD的关键就是测试)。但是，最重要的问题是QA需要直接全程参与到敏捷过程中，作为团队的整体对测试进行设计，与此同时，需要应对需求和解决方案的不断演变。项目管理者联盟
QA需要知道敏捷方法论的真正影响，对业界关于敏捷测试的各种"神话"作出正确的诠释和回应，以下列举了10大著名的"神话"：项目管理者联盟文章
神话1：“你只需要 单元测试 就行了—TDD的测试是足够的”转自项目管理者联盟
这显然是不对的。即使是狂热的敏捷开发者也意识到需要包括很多其他的测试技术。例如，Scott W . Ambler就在他的FLOOT(Full Life Cycle Object-Oriented Testing)方法论中列举了21种不同的测试技术，包括 白盒测试、黑盒测试、 回归 测试、压力测试和用户验收测试(User Acceptance Testing)，参见http://www.ambysoft.com/essays/floot.htmlwww.mypm.net
TDD中的程序员依赖这些测试来验证他们代码的正确性。如果需求(或者说 测试 用例 )没有被正确地描述，那么你可能构建了足够健壮的代码，但是不能满足目标。项目管理者联盟
因此，大部分敏捷项目包括调查性质的测试(黑盒)，用于补充白盒的测试。好的调查性质的测试能尽早揭露开发人员遗漏的问题。项目管理者联盟文章
神话2：“你可以重用单元测试来构建回归测试套件”项目管理者联盟
有些TDD的追捧者提出传统的测试不再需要，因为每一行代码都有相应的单元测试用例了;他们认为，通过重新组合单元测试，可以替代从用户验收测试到回归测试的所有测试类型。项目管理者联盟
虽然这听起来很诱人，但是这不现实，因为：TDD中开发的白盒的单元测试的粒度和目标与黑盒测试有所区别。training.mypm.net
单元测试的总体目标是用于证明代码是如预期般工作的，而回归测试的目的是确保修改的代码不会引起非预期的结果。两者存在的意义是不一样的，例如，"检查某个属性的日期格式是正确的"，就与"对于给定的输入，检查其值具有预期的日期"不一样。项目管理者联盟
神话3：“我们不再需要 测试人员 、或者自动化工具”项目管理培训
专业的测试人员履行了不一样的职责，与开发同僚们一样是不可或缺的项目组角色之一。项目管理者联盟
不得不承认：传统的自动化 测试工具并没有像厂商们所鼓吹的那样神奇。但是这不意味着我们要放弃自动化工具，我们仍然期待更多更好的自动化工具的出现。项目管理者联盟
 项目管理者联盟
神话4：“有了单元测试，手工测试就没有存在的必要性了”项目管理者联盟文章
手工测试时重复性的劳动，代价高、繁琐、容易出错。然而，虽然TDD能减少一定量的手工 功能测试，它并不能废除进一步的黑盒测试的需要(无论是手工的还是自动化的)。training.mypm.net
通过自动化的捕获测试人员的操作过程，并且将他们的键盘和鼠标点击事件文档化，测试人员可以把更多的时间放在有趣的、增值的活动上，例如测试那些自动化很难实现，或者是根本不可能实现的复杂测试场景。虽然通过手工测试寻找 bug是一个耗时的、代价高昂的过程，但是如果不采用这种手段而遗漏了BUG，代价会更高。bbs.mypm.net
神话5：“不再需要用户验收测试”talent.mypm.net
|
