敏捷测试需注意的五种危险行为

发表于:2009-05-04来源:作者:点击数: 标签:危险行为
如果 开发 团队采用了 敏捷 方法,那就意味着 程序员 需要做更多的 软件测试 。然而,这并不是说软件 测试人员 就没事做了。他们需要调整,并学会与以往不同的测试方式。 DragonFire公司的顾问Janet Gregory认为,对用户 需求 的测试尤为重要,“除非经过测试
 如果开发团队采用了敏捷方法,那就意味着程序员需要做更多的软件测试。然而,这并不是说软件测试人员就没事做了。他们需要调整,并学会与以往不同的测试方式。

  DragonFire公司的顾问Janet Gregory认为,对用户需求的测试尤为重要,“除非经过测试,否则不能认为任何业务需求已经完成。

  STAREAST测试展会(STAREAST Conference and Testing Expo)上,Gregory讨论了“新晋敏捷测试员的危险行为与陷阱”,并解释了敏捷测试员所应做的工作。她指出软件测试人员经常做出的危险行为,这些危险行为可能带来的风险,以及如何规避这些危险和风险。

  作为一名敏捷测试员,你需要能在没有正式说明文档的条件下展开软件测试、进行实时测试、测试改动代码、根据不断变化的需求进行测试、自动化大部分测试,并成为紧密合作的团队中的一员。

  如果你想一一完成这些工作,就可能会在努力过程中遇到Gregory所说的敏捷测试的危险行为。

危险行为1:等待第二天的版本

    Gregory认为,敏捷开发需要不断地进行测试。你不能等版本开发到最后阶段才开始软件测试。怎么知道你是否已经陷入这种困窘呢?对照以下几个特征:

        成堆的“等待”测试的业务需求 
        没有在一次迭代周期中测试完所有需求 
        没有定期对部署进行软件测试 
        造成无法进行定期测试的原因包括:未对需求进行测试、软件测试人员不可靠、速度受到影响,以及利益相关人的反馈不够及时等。另外,有可能进行到下一个需求开发的时候,才发现前面未查出的漏洞,或者如Gregory所说,“所有测试都堆到最后阶段”。

        她还说,要避免这种危险,最重要的是要采取主动。从“版本主管”那里定期拿到各版本,并规划测试的基本架构。拿到版本后要尽快测试,包括速度规划(Velocity planning)中的任务,并尽可能地在程序员的机器上进行结队测试,使程序员习惯于得到反馈。

        Gregory说,要找到测试与程序编写之间的平衡点。“只是一味地努力提高速度是不行的。你得让你的工作速度与效率与程序员保持一致。”

危险行为2:你并没有真正地加入团队

  如果软件测试人员没有被邀请参加规划讨论会,或者测试人员不喜欢发言;如果业务客户独立编写业务需求,而测试人员不明白这些需求的内容,这时就已经很明确是否存在这方面的问题了。

    这种工作方式可能导致的后果是:

        无法及时确定各种假设 
        不能及时发现对系统造成的影响 
        员工不能有效利用时间与技能 
        你总是感觉不对劲 
        人心分散 
        Gregory认为,要避免这种情况,你必须强调“完整团队”的重要性。与你的程序员坐在一起,这样你们会更容易交谈;参加各种会议,确保在讨论需求的时候所有三方团队都在场,并建议他们在一两个迭代周期中“尽量尝试”一些新主意。
 
        你得明白作为一名测试员应发挥的作用。也就是Gregory所说的不断地进行软件测试,并提供反馈意见。

原文转自:http://www.ltesting.net

评论列表(网友评论仅供网友表达个人看法,并不表明本站同意其观点或证实其描述)