Janet Gregory敏捷测试教练，以及公司的流程顾问。她和Lisa Crispin一起合著了《更敏捷的测试：整个团队的学习之旅》和《敏捷测试：测试人员和敏捷团队实践指南》
如果开发团队采用了敏捷方法，那就意味着程序员需要做更多的测试。然而，这并不是说软件测试人员就没事做了。他们需要调整，并学会与以往不同的测试方式。
DragonFire 公司的顾问珍妮特·格雷戈里（Janet Gregory）讨论了“新晋敏捷测试员的危险行为与陷阱”，并解释了敏捷测试员所应做的工作。
1. 等待第二天的版本
格雷戈里认为，敏捷开发需要不断地进行测试。不能等版本开发到最后阶段才开始测试，最重要的是要采取主动。
敏捷测试者需要做的是，从“版本主管”那里定期拿到各版本，并规划测试的基本架构。拿到版本后要尽快测试，并尽可能地在程序员的机器上进行结队测试，使程序员习惯于得到反馈。
2. 并没有真正地加入团队
如果测试人员没有被邀请参加规划讨论会，或者测试人员不喜欢发言，亦或是业务客户独立编写业务需求，而测试人员不明白这些需求的内容，这时就已经存在问题了。
要避免这种情况，敏捷测试者必须强调“完整团队”的重要性。与程序员坐在一起，这样就会更容易交谈；也可以参加各种会议，确保在讨论需求的时候，所有三方团队都在场，并建议他们在一两个迭代周期中“尽量尝试”一些新主意。
3. 无法放弃“质量监督”的理念
在敏捷开发中，整个团队都要对质量负责，而不仅仅是测试人员。如果没有整个团队对质量问题的一致认同，程序员就会将测试员看作是安全保障，从而只在 bug 追踪系统中与测试员沟通，那么这个团队便无法“凝聚到一起”。
要改变这种局面，所需要的仍然是测试人员的主动，他们要与程序员建立良好的关系，向程序员展示各自的职业价值，使整个团队对产品的质量负责。
4. 所有测试都想手工进行
如果所有测试都想手工进行，那么必然赶不上程序员的进度。不对测试进行自动化会导致越来越多的 bug，并且无法及时响应新的需求。此外，可能无法注意到以往运行正常的功能已经受损，而测试人员也容易陷入陈规，无法学到新东西。
5. 忽视大局
在敏捷开发中，开发者必须能够展望全局，而不能被一些片面的东西迷惑。如果不能掌握全局，那么业务需求将无法联系到一起，各单元无法集成，业务流程不流畅，并且在编写程序过程中制定的决策也无法与最终目标吻合。
格雷戈里建议，如果能先进行验收测试，用面向业务（business-facing）的测试进行有效的开发，充分考虑系统其它部分受到的影响，使用可以反映实际情况的测试数据，以及在编写程序之前将业务需求研究透彻，就能避免这一切。
欢迎分享敏捷测试的优点和遇到的问题 : )
