敏捷测试过程
敏捷测试敏捷在流程的定义上，并不是敏捷在测试角色定义上，如果你想保证测试的终有效性，请不要随意修改或者删除这些已经定义的测试角色和其相关职责。敏捷测试过程同样存在着一个成熟度模型，5个级别的成熟执行
过程。我个人认为测试成熟度模型不必过于复杂，每一个层次的可明确定义是重要的，和所有的软件开发模型一样，每个阶段都有其向上一层次进化的路径。在研究测试成熟度模型的时候，我发现一个非常有意思的事实，很多
公司都急于把测试的初阶段迅速提高到终第五层次，当他们迷信的投入的大量资源的同时，却得到了失败的下场。
测试成熟度的各个阶段进化过程都需要定量的时间，明确的工作角色被分配，这些都是向下一级过渡的必要条件。同样，测试成熟度也关联了一个测试人员的职业成熟度，即使测试成熟度达到了，没有相关联的测试人员，整
体执行的结局还是失败，这和极限编程的某些理论一致：某些特定角色是整个团队的灵魂。
初始阶段（Ⅰ级）
测试成熟度的初始阶段主要表现为以下特征：
1. 无专职测试人员参与。
2. 项目团队无测试意识或者测试意识淡薄。
3. 测试动作表现为混乱无序状态，测试等同于个人调试行为。
4. 测试在编码后任意进行。
5. 软件开发过程无质量保证，无相关资源投入。
6. 无测试管理，测试无目标。
7. 在整个软件开发过程中，测试不是一个重要的参与环节。
事实上大部分的国内公司都是这样的，对软件测试不是很重视，并且部分项目管理者自身也不懂软件测试，如果再采用“盖鸡窝”软件开发方式，那么出现十个项目九个崩溃的情况是不足以为奇的。测试虽然不能从终意义上保
证软件的整体质量，但是它能及时的反馈当前软件质量状态，有助于及时的发现问题快速的改正问题，需要注意的是，敏捷测试在某些特定情况下支持开发团队全面负责软件测试任务。
已定义阶段（Ⅱ级）
测试成熟度的已定义阶段主要表现为以下特征：
1. 测试和调试已经分离。
2. 测试在编码后进行，或者在产品即将发布的后有限规定时间内进行。
3. 掌握了部分基础测试方法和基础测试理论，具备一些必要的测试角色和支持角色。
4. 测试角色职责模糊，无准确定义。
5. 具备了部分基础测试输出工件，如测试计划等。
6. 测试管理少量涉及，但控制手段不明显，无很好的风险规避手段。
7. 介入了基础的BUG管理机制，但是对BUG的控制手段软弱造成遗失。
8. 在整个软件开发过程中，测试已经成为一个概念重要，实施力度过于软弱的参与环节。
属于该阶段的，尚未分化的测试个体已经具备了少量的服务能力，测试和调试的分离意味着测试任务已经被单独剥离出来，交付给更具备专业能力的人处理。该阶段已经出现了对BUG进行管理的意识，这意味着很大程度上项目
组或者测试个体可以在一定程度上对已经发现的BUG作微弱的控制，所以在这个阶段不应该对软件构成的质量抱有多大的幻想，我们只要知道这只是一个简单的开始。
可持续集成阶段（Ⅲ级）
测试成熟度的可持续集成阶段主要表现为以下特征：
1. 测试集成到项目的各个迭代阶段中，已经不再体现为编码后测试。
2. 测试切入了需求阶段、设计阶段，并且针对这两个阶段产生了独立的正式技术复审手段。
3. 已经有专门的机构负责，相应的体系被建立，大部分测试角色职责定义清晰，投入资源相对稳定。
4. 对测试的各个阶段工件输出做出了限定，并且根据项目的历次迭代制订了测试发布后基线。
5. 测试管理中已经介入风险管理制度，具备一定的规避手段。
6. 使用了部分测试工具和启用了专门的BUG管理工具（于收集管理）
7. 测试的领域大部分限定于黑盒阶段。
8. 有了正规技术培训的活动。
9. 考察和评审基础数据匮乏，无法实施测试度量。
该阶段正式分化了独立的测试个体或者测试团队，他们已经具备了一定的服务能力，大部分执行的测试项目都采用了迭代思想，并且在任何一次迭代的开始都会产出一份经过仔细确认的执行风险列表。测试已经不再表现为单纯的
编码测试方式，软件开发中包含的大部分核心过程都已经被监管（有限的），表现为不同的测试的执行方式。BUG有专门的管理工具收集，比如运用了某些商业数据库。初步产生了自动化测试概念，但是由于本身条件的制约，
导致测试个体或者测试团队不能更进一步的深入概念中，测试依然以黑盒测试为执行主体。
