Leadge.com首页 > 知识库
文章搜索
我对敏捷测试的体会
2009-2-17 9:52:12  作者:佚名
  “沟通”成了最重要的技能之一

  敏捷宣言里讲:个体和交互胜过过程和工具,客户合作胜过合同谈判。在内部需求上,开发人员就是我们的客户。而我在加入团队后所做的第一件事,就是搬位子到开发人员旁。当然,是被要求这么做的。一开始还有点不适应,毕竟我们被分离开了曾引以为豪的独立的测试团队,这和传统的观念是相悖的。不过在经历过几个测试阶段后,这么做的好处就体现了出来。

  以往我们总要等到一个正式的版本,才可以开始测试,否则过多的介入会打乱开发计划。而现在,程序员就坐在我对面的隔间,他一抬头就说:“嘿,X功能做好了,我跑了一遍没问题,你来试试看?”结果我过去试了试,bug出来了。程序员的反应则是:“好,我马上改”。——这样一个bug从发现到修正,最多不超过半个小时。而以往,我要等到版本正式提交,再build好,再up好,发现bug后还要通过提交bug管理系统,等待系统发邮件给程序员。如果恰好程序员忘记开邮箱了,那就可能要更多的时间。

  事实上这里面还有更多的细节。我相信大多数测试人员会和我有同样的经历,在发现并提交一个bug时,我们写了大量的文字来描述bug的环境,bug的重现步骤;程序员修正bug时,也自信满满的说,该bug已修正。但当你一复查时,却发现你所认识的那个bug还在,而程序员完全理解错了你所说的bug。而现在,你所需要做的,只是抬一下头,把问题说出来,直接和程序员进行沟通,让他能够准确的理解你的意思,甚至包括你对于该bug的分析。接下来一切就十分好办了。

  此外,有时有些bug确实不是那么容易重现的,你需要和程序员配合操作,才能发现其中的蛛丝马迹。我们现在最常做的一种合作就是,由我来制造环境,按重现步骤操作,由程序员在另一端跟踪调试代码,一边沟通,一边进行,这样就能很准确的发现问题,并且能很快的得到修正。

  仅仅是几句话的沟通,就能将一个bug在最短的时间内修正,这节省了多少时间?这皆得益于比以往更便捷的沟通。而我们所做的,不过是移动了一下位子,减少了我们之间的沟通成本,却大大的提高了开发效率——我已经记不清有多少bug在还没提交之前就被消灭掉了。但这也对我们测试提出了更高的要求,虽然之前的我们也很强调沟通能力,但现在由于需要更频繁的沟通,我们对沟通能力的提高也变得也越来越重要,成为了最重要的技能之一。

  说到这里,其实我们已经能感受到,测试的角色定位已经变了。因为敏捷开发中,要对质量负责的是整个团队,这一目标就要求测试人员不再是一个独立的质量监督部门,而是要融入到整个团队中,成为开发中不可分割的一部分。

  调整测试用例的粒度

  敏捷宣言里还说,可以工作的软件胜过面面俱到的文档,响应变化胜过遵循计划。那么我们是不是可以都不要文档,不用写用例了呢。我想,如果你的项目是一个“Hello world多国语言版”,大可以如此。但如果是面对一个大型的,多人的,在线的,角色扮演游戏,还是算了吧。

此文章共有3页  1 2 3 下一页

文章来源:中国项目管理资源网

发表评论    【推荐】 【打印
我来评两句 查看最新评论〗 
请您注意:
·遵守中华人民共和国的各项有关法律法规
·承担一切因您的行为而导致的法律责任
·本网留言板管理人员有权删除其管辖留言内容
·您在本网的留言,本网有权在网站内转载或引用
·参与本留言即表明您已经阅读并接受上述条款
昵称: 匿名
 
图片广告
热点文章
论坛精贴