与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始终在强调要以人为本的敏捷思想：

　　人和人之间的关系很重要，包括团队与客户，团队中的各个人员之间，都应该是一种合作的关系，而不是对立的关系;

　　要积极地交流和反馈，了解情况和状态并加以调整。

　　招聘新人的时候，不仅仅要看特定的技术，那可以通过培训的方式教给他们，更重要的是看他是否能够很好地融入到团队中。

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

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

　　作者：侯伯薇@大连

　　出处：http://www.cnblogs.com/houbowei/

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