独立测试团队在敏捷开发中的几个特别实践

[原文发表在https://hespr.blogspot.jp/2009/03/blog-post.html 写在2009年3月

最近发现被人盗版了多处, 重新发布在CSDN]

最近读了《我和敏捷团队的五个约定》（from InfoQ），很是赞同，但是那些约定不少本来就来自于传统方法，似乎并没有体现敏捷团队的特点。

在敏捷开发的测试方面有没有不一样于传统开发测试的并且是有效的实践？

从敏捷团队的组建上来说，敏捷团队并没有要求安排专门的测试人员，甚至于在某些的方法中不建议清楚的区分开发人员角色和测试人员角色。 本文讨论的是已经存在独立测试团队的情况，如何在敏捷开发中进行高效的测试。

实践1：测试保护开发

通过快速的自动化测试跟进开发，保证新增和修改不破坏已经获得的成果。

典型步骤如下：

1，开发人员根据需求，采用TDD，编写代码，实现界面和接口。

2，几乎同步，测试人员编写自动化测试，主要是黑盒自动化测试，也不排除白盒自动化测试。

3，一般保证，代码出来后的第2天，相关的自动化测试代码开发完成。

实践2：成为大敏捷团队的成员

子实践1：参加相关会议，如果是SCRUM，参加SCRUM所有要求的会议。

子实践2：可以阅读和修改最大范围的配置项（比如文档，代码，工作项）

子实践3：一起工作，比如把位子搬到开发人员旁边，如果同时参加多个项目，选择一个较近距离的位子。

说明：这个实践本身的宗旨与传统做法并无根本区别，这里的区别在于程度。

实践3：与定期构建一起执行测试人员的自动化测试用例，或者定期构建包括测试人员的自动化测试。

这里用了”测试人员的自动化测试用例“，也有做法是测试人员和开发人员一起维护自动化测试用例，并没有“测试人员的自动化测试用例“，这里主要说明无论测试人员贡献的自动化测试用例处于何种形式，无论构建是否包括测试人员的自动化测试用例，就是要求自动化测试能与构建为基来执行。

子实践1：维护一套自动化测试环境，可以自动获得最新的##测试用例和构建成果

子实践2：测试结果可以自动发布到合适的地方，缺陷得到跟踪管理

实践4：设计更多黑盒手工场景化测试用例，安排更多随机场景测试

关 注于局部功能的测试用例在敏捷开发中往往已经被自动化实现了。因此为了发布的测试中，值得设计更多黑盒手工场景化测试用例。选择一些典型场景化测试用例开 发为自动化测试用例也是可以的，但是此类测试用例的自动化开发所需工作量较大，要看测试团队的投入和质量目标安排，如果有象微软一样的测试开发工程师，就 另当别论了。一般而言，从经济角度出发，黑盒手工场景化测试用例是发现潜在缺陷的有效且经济的手段，如果存在丰富经验的测试人员，随机场景测试也是值得更 多采用的。本实践在传统测试中也有，这里要强调的特别之处是可以考虑手工测试全部用场景化测试，大幅减少针对单一功能或局部功能的测试用例。

对测试人员的要求

从以上实践可以看到，测试人员所要掌握的技能有黑盒自动化测试、场景化测试，最好也要常握白盒自动化测试，定期构建和自动测试报告

工具支持

常见的有fit,fitnesse, white, watir, selenium, cruisecontrol, QTP, robot, xUnit系列，xFit系列等等

效果和校验

上述的实践是否有效、是否高效，可以观察如下几点：

1，达到发布条件所需的测试轮次是否减少？测试缺陷密度是否减少？

2，获得快速发布的能力，发布工期偏差是否减小？

3，测试所需总的工作量是否在测试团队承受的范围之内，尤其关注测试后期的工作量是否大幅减少，减少的数量是否比在测试前期增加的数量要更大？

如果没有获得正面收益，就需反思了。