前日，加拿大的敏捷测试专家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始终在强调要以人为本的敏捷思想：
- 人和人之间的关系很重要，包括团队与客户，团队中的各个人员之间，都应该是一种合作的关系，而不是对立的关系；
- 要积极地交流和反馈，了解情况和状态并加以调整。
- 招聘新人的时候，不仅仅要看特定的技术，那可以通过培训的方式教给他们，更重要的是看他是否能够很好地融入到团队中。
不知不觉，大家聊了差不多三个小时，仍然意犹未尽。不过只能彼此告别，希望以后还有机会做这样的交流。
如果你对于敏捷和测试方面有什么看法，欢迎对本文进行评论，:)
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
