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

发布时间:2016-12-7 0:01:42 编辑:www.fx114.net 分享查询网我要评论
本篇文章主要介绍了"敏捷测试需注意的五种危险行为",主要涉及到敏捷测试需注意的五种危险行为方面的内容,对于敏捷测试需注意的五种危险行为感兴趣的同学可以参考一下。

如果开发团队采用了敏捷方法,那就意味着程序员需要做更多的软件测试。然而,这并不是说软件测试人员就没事做了。他们需要调整,并学会与以往不同的测试方式。   DragonFire公司的顾问Janet Gregory认为,对用户需求的测试尤为重要,“除非经过测试,否则不能认为任何业务需求已经完成。 ”   STAREAST测试展会(STAREAST Conference and Testing Expo)上,Gregory讨论了“新晋敏捷测试员的危险行为与陷阱”,并解释了敏捷测试员所应做的工作。她指出软件测试人员经常做出的危险行为,这些危险行为可能带来的风险,以及如何规避这些危险和风险。   作为一名敏捷测试员,你需要能在没有正式说明文档的条件下展开软件测试、进行实时测试、测试改动代码、根据不断变化的需求进行测试、自动化大部分测试,并成为紧密合作的团队中的一员。   如果你想一一完成这些工作,就可能会在努力过程中遇到Gregory所说的敏捷测试的危险行为。 危险行为1:等待第二天的版本     Gregory认为,敏捷开发需要不断地进行测试。你不能等版本开发到最后阶段才开始软件测试。怎么知道你是否已经陷入这种困窘呢?对照以下几个特征:         成堆的“等待”测试的业务需求          没有在一次迭代周期中测试完所有需求          没有定期对部署进行软件测试          造成无法进行定期测试的原因包括:未对需求进行测试、软件测试人员不可靠、速度受到影响,以及利益相关人的反馈不够及时等。另外,有可能进行到下一个需求开发的时候,才发现前面未查出的漏洞,或者如Gregory所说,“所有测试都堆到最后阶段”。         她还说,要避免这种危险,最重要的是要采取主动。从“版本主管”那里定期拿到各版本,并规划测试的基本架构。拿到版本后要尽快测试,包括速度规划(Velocity planning)中的任务,并尽可能地在程序员的机器上进行结队测试,使程序员习惯于得到反馈。         Gregory说,要找到测试与程序编写之间的平衡点。“只是一味地努力提高速度是不行的。你得让你的工作速度与效率与程序员保持一致。” 危险行为2:你并没有真正地加入团队   如果软件测试人员没有被邀请参加规划讨论会,或者测试人员不喜欢发言;如果业务客户独立编写业务需求,而测试人员不明白这些需求的内容,这时就已经很明确是否存在这方面的问题了。     这种工作方式可能导致的后果是:         无法及时确定各种假设          不能及时发现对系统造成的影响          员工不能有效利用时间与技能          你总是感觉不对劲          人心分散          Gregory认为,要避免这种情况,你必须强调“完整团队”的重要性。与你的程序员坐在一起,这样你们会更容易交谈;参加各种会议,确保在讨论需求的时候所有三方团队都在场,并建议他们在一两个迭代周期中“尽量尝试”一些新主意。           你得明白作为一名测试员应发挥的作用。也就是Gregory所说的不断地进行软件测试,并提供反馈意见。 危险行为3:无法放弃“质量监督”的理念   可能你以前工作在一个质量监督(Quality Police)负责所有质量问题的环境下。即除开发团队以外,有一个单独的软件测试团队将所有的漏洞报告到缺陷跟踪系统中,测试团队甚至可以停止开发的进行。   然而,在敏捷开发中,整个团队都要对质量负责,而不仅仅是测试人员。Gregory说,如果没有整个团队对质量问题的一致认同,程序员就会将软件测试员看作是安全保障,从而只在bug追踪系统中与测试员沟通,那么这个团队便无法“凝聚到一起”。   要改变这种局面,所需要的仍然是测试人员的主动。Gregory指出,软件测试人员要与程序员建立良好的关系,向程序员展示各自的职业价值,使整个团队对产品的质量负责。     测试员可以在一些专业问题上帮助程序员,保证能够在迭代过程中进行测试,并解释对于整个团队来说“完成”所代表的意义。在追踪bug时,可以使用需求卡片(index card)。将需求开发中发现的bug写到卡片上并贴到墙上。 危险行为4:所有测试都想手工进行   Gregory说,如果所有测试都想手工进行,那么必然赶不上程序员的进度。如果你一直把时间用在重复进行某些测试上,而没有对新功能进行测试;或需要越来越多的软件测试人员,却无法对部署或设计上的问题产生作用,你就会明白这个问题的重要性。   不对测试进行自动化会导致越来越多的bug,并且无法及时响应新的需求。此外,可能无法注意到以往运行正常的功能已经受损,而软件测试人员也容易陷入陈规,无法学到新东西。    对此Gregory提出以下建议: 用自动化的方法建立回归测试集 设计时考虑到易测试性 使自动化与测试同步(让程序员也参与) 帮助程序员编写优良的单元测试 使用对整个团队都有用的自动化工具 展示你的技能 推广你的工具包 危险行为5:忽视大局   在敏捷开发中,你必须能够展望全局,而不能被一些片面的东西迷惑。如果你发现一直进行的只有单独的需求测试,在发布的版本中有集成的bug,直到最后才制作报告,而你所做的测试都是程序员告诉你去做,并且只做了探索性测试,那么你肯定是没有考虑整体规划。   如果确实如此,那么你的业务需求将无法联系到一起,各单元无法集成,业务流程不流畅,并且在编写程序过程中制定的决策也无法与最终目标吻合。Gregory说:“你在冒险,你的最终产品可能并不是所需要的。”   如果能先进行验收测试,用面向业务(business-facing)的测试进行有效的开发,充分考虑系统其它部分受到的影响,使用可以反映实际情况的测试数据,以及在编写程序之前将业务需求研究透彻,便能避免这一切。    还有一些可以使用的方法,包括: 使用电子公告栏进行规划 详细考虑业务流程 进行探索性测试 使用实例 先进行验收测试 让程序员拒绝进行没有测试的代码编写工作     这些危险行为看起来很可怕,但它们是可以控制的。然而,新团队可能需要一位敏捷指导员来帮助鉴别并解决这些问题。Gregory还建议参与到雅虎(Yahoo)敏捷测试小组的活动中,并研究相关文章。     她说:“敏捷测试中充满了危险的行为。你要认识并注意到这些危险行为,但别让它们吓倒你。”  

上一篇:hdu2487(枚举)
下一篇:在Linux中使用蓝牙

相关文章

相关评论