如果您的公司正在实践敏捷开发，你可能已经遇到和George Wilson相同的挑战。作为AIG Computer Services的Business Group Manager，他同时还在TickIT管理环境中管理IBM 中端和PC开发项目，这些都需要ISO9001的QA认证。现在，作为测试自动化工具厂商Original Software的共同创始人和总经理，他开始布道敏捷实践，作为达到质量的最佳方式。
“敏捷项目对于QA来说，是一个领导（测试）整个过程极好的机会，”Wilson说。不该是开发者掌舵整个过程，测试员只是次要的地位，他推荐测试员应该带头起领导作用。“还有其他更好的人能消除用户和开发者之间的鸿沟吗？理解什么是必需的，怎样才能达到目标？在发布之前如何确保质量？”这就要求QA team自身在敏捷活动中非常灵活，所以Wilson 列举了以下的事实来揭穿一些常见的敏捷测试的谎言。
谎言一：你需要做单元测试——TDD测试足够了
TDD（测试驱动的开发 Test Driven Development）是一个好的开始，但是对于那些认为TDD就是全部的人，“对于绝大多数的商业开发来说，这显然是不对的。即便是敏捷开发的强烈支持者也认识到使用大量测试技术的必要性….包括白盒测试、黑盒测试、回归测试、压力测试和用户验收测试（UAT），”Wilson说。
因此，最有效的敏捷项目将会包括探索性测试（黑盒测试）的技术补充（而不是竞争）白盒测试。“好的探索性测试将会在陷入深渊之前，发现开发者遗漏掉的问题。”Wilson说。
谎言二：你可以重用单元测试，构建回归测试集
传统的位于开发活动后期的测试不是必要的，因为应用程序的每一行代码都有对应的测试用例，有人曾经告诉过你吗？“一些TDD支持者…建议通过重新组织单元测试，从用户验收测试（UAT）到回归测试的一切都可以执行。Wilson说。
听起来好像很有道理，Wilson认为这实际上是不现实的，因为TDD开发的白盒单元测试的粒度和目标，和后期的黑盒测试，目的完全不一样。“单元测试全部的目标是验证代码做预期的事，回归测试的目标是保证修改后的应用代码没有意料之外的，或者是意外的结果。”这两个目标不完全相同。如，检查一个属性是有效的日期格式，和对于给定的输入，检查字段的值包含预期的日期，是不同的。
谎言三：我们不再需要测试员或者自动化工具
此文章共有2页 1 2 下一页
文章来源：中国项目管理资源网
|
Leadge.com首页 > 知识库 
