如果开发团队采用了敏捷方法，那就意味着程序员需要做更多的测试。然而，这并不是说软件测试人员就没事做了。他们需要调整，并学会与以往不同的测试方式。
DragonFire公司的顾问Janet Gregory认为，对用户需求的测试尤为重要，“除非经过测试，否则不能认为任何业务需求已经完成。
”
STAREAST测试展会（STAREAST Conference and Testing Expo）上，Gregory讨论了“新晋敏捷测试员的危险行为与陷阱”，并解释了敏捷测试员所应做的工作。她指出测试人员经常做出的危险行为，这些危险行为可能带来的风险，以及如何规避这些危险和风险。
作为一名敏捷测试员，你需要能在没有正式说明文档的条件下展开测试、进行实时测试、测试改动代码、根据不断变化的需求进行测试、自动化大部分测试，并成为紧密合作的团队中的一员。
如果你想一一完成这些工作，就可能会在努力过程中遇到Gregory所说的敏捷测试的危险行为。
危险行为1：等待第二天的版本
Gregory认为，敏捷开发需要不断地进行测试。你不能等版本开发到最后阶段才开始测试。怎么知道你是否已经陷入这种困窘呢？对照以下几个特征：
成堆的“等待”测试的业务需求
没有在一次迭代周期中测试完所有需求
没有定期对部署进行测试
造成无法进行定期测试的原因包括：未对需求进行测试、测试人员不可靠、速度受到影响，以及利益相关人的反馈不够及时等。另外，有可能进行到下一个需求开发的时候，才发现前面未查出的漏洞，或者如Gregory所说，“所有测试都堆到最后阶段”。
她还说，要避免这种危险，最重要的是要采取主动。从“版本主管”那里定期拿到各版本，并规划测试的基本架构。拿到版本后要尽快测试，包括速度规划（Velocity planning）中的任务，并尽可能地在程序员的机器上进行结队测试，使程序员习惯于得到反馈。
Gregory说，要找到测试与程序编写之间的平衡点。“只是一味地努力提高速度是不行的。你得让你的工作速度与效率与程序员保持一致。”
危险行为2：你并没有真正地加入团队
如果测试人员没有被邀请参加规划讨论会，或者测试人员不喜欢发言；如果业务客户独立编写业务需求，而测试人员不明白这些需求的内容，这时就已经很明确是否存在这方面的问题了。
这种工作方式可能导致的后果是：
此文章共有2页 1 2 下一页
文章来源：中国项目管理资源网
|
Leadge.com首页 > 知识库 
