与Janet关于敏捷测试若干问题的Q&A

前日,加拿大的敏捷测试专家Janet Gregory来到大连,程序员社区为其举行了小型的聚会,大家一起共进晚餐,期间大家提出了很多问题,Janet基于自己的经验给出了很好的建议,大家受益良多,不敢独享,简单在此记录,供大家讨论。

Q:当前团队所从事的项目比较小,因此在结对编程之外,没有安排专门的测试人员。但随着团队的增大,是否有必要增加这样的角色?

A:首先要确定团队是否已经出现了问题,也就是说,没有专门的测试人员,项目的质量和进度会发生很大的问题。敏捷的目的在于解决问题,如果没有问题,那么就说明当前的机制能够满足当前的需要,并不一定要进行调整。

当团队增大的时候,有专门的测试人员是必要的,因为测试人员的思维和开发人员的思维是不一样的,往往可以从另一个角度发现问题,从而更好地保证质量。特别是在做产品的时候,更有必要有测试人员(有些小型的项目里面,客户会代替测试人员从事测试的工作)。

在做比较大的项目的时候,需要识别出很多用户故事(user story),然后根据这些用户故事,把所要做的工作切分成小块,然后以迭代的方式进行,迭代的周期最好是一周或者两周,每次迭代的时候要召开整个团队的迭代会议,让大家都明确这次迭代中所要完成的用户故事。

Q:迭代会议需要哪些人员参加?

A:整个团队,包括设计人员、开发人员、测试人员,最好还能够把客户也加入进来,这样可以在会上明确所有的问题。并且应该是整个项目组的成员都要参加,并不是说,不做某一个功能,就与之无关,就不需要了解那个部分的内容,每个人都需要对整个项目有全盘的了解。

另外重要的是要举行每日的站立会议,那也是交流的重要方式。

Q:当团队需要增加专门的测试人员时,可以有两种选择:1)招聘专门从事测试的人员 2)从有意愿的程序员中选择,转换为测试人员的角色。这两种哪一种更好一些呢?

A:开发人员和测试人员的思维方式应该是不同的,所以最好有专门从事测试的人,而不是从程序员中挑选。尽管拥有一定的编程知识能够更有益于找到程序中的缺陷,并且可能更好地帮助开发人员找到原因,甚至定位缺陷的原因,但思维是首先要解决的问题。

另外,开发人员和测试人员应该是相互合作的关系,这种合作不一定是在开发人员完成了程序之后,可能在开发人员写代码之前,测试人员就可以编写测试案例,然后和开发人员讨论,比方说:你看,我有这么多的测试案例要在稍后测试,你可以先了解一下。有了这种提前的合作,开发人员在编写代码的时候就会避免很多错误,从而提高程序的质量。

Q:一个人可否兼任两个项目的测试人员?

A:不建议。因为这样就无法满足每天工作八个小时的要求,因为会有在两个项目之间切换的时间,不仅仅是环境、工具、技术的切换,还包括思维的切换。在加拿大,和美国不同的是,人们的加班比较少,因为在工作的八个小时之内都能够正常运转,尽可能地完成工作。每周工作四十个小时的团队,并不一定比整天加班的团队完成的工作少,更不一定会拖慢进度。

Q:在敏捷团队中是否一定要使用TDD(测试驱动开发)?

A:这里的经验是来自于他人,并不是我(Janet)自己的经验。并非所有团队都愿意转为TDD,但是使用了TDD的团队都反馈说,他们很喜欢这种方式,不想再回到原来的方式了。但是,对于TDD来说,开始的起步是最困难的,因为那需要转换工作的思维方式。

此外,Janet还和大家演示了如何使用积分扑克,那是一种很好玩的方式,可以用来评估user story所需要的工作量,而且是比较有效的。

贯穿始终,Janet始终在强调要以人为本的敏捷思想:

  • 人和人之间的关系很重要,包括团队与客户,团队中的各个人员之间,都应该是一种合作的关系,而不是对立的关系;
  • 要积极地交流和反馈,了解情况和状态并加以调整。
  • 招聘新人的时候,不仅仅要看特定的技术,那可以通过培训的方式教给他们,更重要的是看他是否能够很好地融入到团队中。

不知不觉,大家聊了差不多三个小时,仍然意犹未尽。不过只能彼此告别,希望以后还有机会做这样的交流。

如果你对于敏捷和测试方面有什么看法,欢迎对本文进行评论,:)

posted @ 2011-09-29 10:08 侯伯薇 阅读(...) 评论(...) 编辑 收藏