危险行为3：无法放弃“质量监督”的理念
可能你以前工作在一个质量监督（Quality Police）负责所有质量问题的环境下。即除开发团队以外，有一个单独的软件测试团队将所有的漏洞报告到缺陷跟踪系统中，测试团队甚至可以停止开发的进行。
然而，在敏捷开发中，整个团队都要对质量负责，而不仅仅是测试人员。Gregory说，如果没有整个团队对质量问题的一致认同，程序员就会将软件测试员看作是安全保障，从而只在bug追踪系统中与测试员沟通，那么这个团队便无法“凝聚到一起”。
要改变这种局面，所需要的仍然是测试人员的主动。Gregory指出，软件测试人员要与程序员建立良好的关系，向程序员展示各自的职业价值，使整个团队对产品的质量负责。
测试员可以在一些专业问题上帮助程序员，保证能够在迭代过程中进行测试，并解释对于整个团队来说“完成”所代表的意义。在追踪bug时，可以使用需求卡片（index card）。将需求开发中发现的bug写到卡片上并贴到墙上。
危险行为4：所有测试都想手工进行
Gregory说，如果所有测试都想手工进行，那么必然赶不上程序员的进度。如果你一直把时间用在重复进行某些测试上，而没有对新功能进行测试；或需要越来越多的软件测试人员，却无法对部署或设计上的问题产生作用，你就会明白这个问题的重要性。
不对测试进行自动化会导致越来越多的bug，并且无法及时响应新的需求。此外，可能无法注意到以往运行正常的功能已经受损，而软件测试人员也容易陷入陈规，无法学到新东西。
对此Gregory提出以下建议：
用自动化的方法建立回归测试集
设计时考虑到易测试性
使自动化与测试同步（让程序员也参与）
帮助程序员编写优良的单元测试
使用对整个团队都有用的自动化工具
展示你的技能
推广你的工具包
危险行为5：忽视大局
在敏捷开发中，你必须能够展望全局，而不能被一些片面的东西迷惑。如果你发现一直进行的只有单独的需求测试，在发布的版本中有集成的bug，直到最后才制作报告，而你所做的测试都是程序员告诉你去做，并且只做了探索性测试，那么你肯定是没有考虑整体规划。
如果确实如此，那么你的业务需求将无法联系到一起，各单元无法集成，业务流程不流畅，并且在编写程序过程中制定的决策也无法与最终目标吻合。Gregory说：“你在冒险，你的最终产品可能并不是所需要的。”
如果能先进行验收测试，用面向业务（business-facing）的测试进行有效的开发，充分考虑系统其它部分受到的影响，使用可以反映实际情况的测试数据，以及在编写程序之前将业务需求研究透彻，便能避免这一切。
还有一些可以使用的方法，包括：
使用电子公告栏进行规划
详细考虑业务流程
进行探索性测试
使用实例
先进行验收测试
让程序员拒绝进行没有测试的代码编写工作
这些危险行为看起来很可怕，但它们是可以控制的。然而，新团队可能需要一位敏捷指导员来帮助鉴别并解决这些问题。Gregory还建议参与到雅虎（Yahoo）敏捷测试小组的活动中，并研究相关文章。
她说：“敏捷测试中充满了危险的行为。你要认识并注意到这些危险行为，但别让它们吓倒你。”
