一、开发组一定不能讳疾忌医。
作为开发人员，一定要秉着这个出发点去看待测试。业务测试测试组测试，自测，与开发组的目标是一致的，都是为了保证和提高项目质量，没有谁要给谁找茬。
二、自测是第一步。
开发组自测必须是白盒测试。必须保证覆盖率。必须是自动化测试。尽量做到交叉测试。
三、测试组测试
测试组的测试应该是最全面、细致的。至少应是黑河测试。尽量做到白盒测试。应该具备各种性能测试的能力。测试组与业务人员、开发组要有有效、及时的沟通。
四、业务测试
业务测试的目的是需求验收。基本只能做到黑盒测试。要做好沟通，并通过测试沟通体现业务需求、设想。
五、整个测试要有统一的记录、反馈渠道。
如果开发组、测试组、业务组人手一份测试记录，很可能出现测试反馈记录遗漏、版本错乱等问题。
六、测试驱动。
测试驱动是个很不错的东西。在迈步子之前先投石问路，就会知道到哪一步应该注意什么。

敏捷开发中的测试，带着敏捷的特点。
一、小版本。
敏捷开发的核心就是小版本需求，针对需求进行测试的功能必然也是小版本的。
二、频率高。
所谓“小步快跑”，小版本带来的另一个特点必然就是测试、反馈频率高。
三、沟通多。
本身敏捷开发的各种沟通就多。测试阶段又会与业务人员直接关联，各种关于需求理解、改动和成本的沟通必然也会增加。
四、测试、反馈带有业务优先级。
根据业务流程的重要性、紧急性，给测试反馈的bug排列优先级。一方面，这种优先级是业务价值的体现，也是敏捷开发的目标；另一方面，这种优先级要求方便开发组安排有限的时间和人力；此外，对优先级的排序还可以从一个侧面反映出业务需求的一些核心思路。
五、开发组自组织、自驱动性强。
关于敏捷开发的自组织和自驱动，我到现在也没有吃透。从已有经验来看，一个大需求分割成小版本，并分派到各开发人员之后，各个小版本的开发、测试等工作基本就有开发人员自己掌握和推动，即使是项目负责人也很难掌握得太细。这是一种自驱动。
六、版本隔离、合并等管理工作要求高。
小版本意味着版本多，版本多意味着版本冲突的风险大。因此，敏捷开发对版本管理的要求也更高。
七、自动化
自动化也是版本多、速度快所要求的。不仅包括测试自动化，还应包括构建自动化、发布自动化等。

我们项目组现有的测试流程
现在的测试流程，借鉴了tx的敏捷流程，采用“测试班车”和“测试包车”的形式组织测试。自测和测试驱动方面开展得不太顺利，还在继续推动之中。
“测试班车”是定期的测试版本。我们的一个冲刺规划为3周。通常，前两周的测试都采取“测试班车”的形式，每隔两天（周二下午和周五上午）发布一个测试版本，交由测试组进行测试。
“测试包车”是不定期的测试版本，什么时候有升级就什么时候包一趟车。我们组通常从第二周开始就会有测试包车。第三周开始将版本发布到stage测试环境上，交由业务组进行测试。第三周的测试反馈和更新基本都是采用包车的形式。
目前测试组的测试反馈统一由mantis系统进行管理。业务组的测试反馈目前没有统一的工具，仅由业务人员整理成统一的文档。