近，我在项目组选择了一个模块尝试一些敏捷测试的做法，试图打破原有测试流程的串行做法，实现更及时的测试。我的尝试主要集中在两个方面。

　　以前我们都是一个版本的开发全部完成后，经过开发人员的集成测试，然后提交测试人员进行测试。手工测试完成后对稳定的功能做自动化测试。在这个流程中，开发和测试完全是串行的。手工测试和自动化测试也是串行的。

　　Scrum引入后，我们用了Story来组织需求。Story之间相对的独立性使得基于story的开发可以逐步提交测试。所以我想进行的第一个尝试“边开发边测试”有了可行性。于是我和开发人员一起草拟了一个基于story的何时结束开发，何时演示，何时开始测试人员的测试的“测试计划”。Scrum强调按照用户价值从高到低来开发story，所以无论是从业务价值还是测试的角度，原本我是想先测试创建功能再测试查询功能的。但开发人员由于对新技术不太熟悉，所以想先开发查询这个相对简单的功能，也免得我一开始要等待很长时间才测试第一个story.我觉得这样也不错，何况也不至于两个story都完成不了，只是一个sprint里暂时的先后，于是讨论后做了调整。“合适的是好的”，在这个调整中我们再次拥抱了敏捷的思想。边开发边测试，看起来很美，好像可以通过并行工作节约时间，但可能主要是因为这次开发人员同时尝试了TDD，开发时间变长，所以我们这次尝试并没有得到这样的结论。而我感到的不适应的痛苦倒是有一些，主要是测试节奏上忽紧忽慢，比以前更多地依赖开发节奏。有时好几天没有东西可以测试，忽然来了一个新版本，感觉测试思路还是有些脱节，不象以前一鼓作气测到手软那么酣畅。当然，好处也是有的。深的感受是由于反馈更及时，一些严重的问题很早被暴露出来（如，extJS对于多浏览器的支持问题在测试第一个story时意识到后期还要花不少精力来处理），或者类似的问题在后续开发中可以及时避免（如，字段长度都忘记验证了）。

　　在这样的一会松一会紧的比较被动的测试中，我的另一个尝试“自动化测试”倒是找到了机会。没有新内容可以测试而原有功能又相对稳定的时候，我利用这些时间将稳定的功能自动化起来。当然，如果测试人员面对更多的开发人员，开发总是比测试快，那么自动化测试可能还要另找时间。但目前，开发人员一边开发新功能，一边修复缺陷，还要写单元测试，好像测试人员的速度还是要快一些的。“自动化测试”也与手工测试并行起来。

　　接下来的新一个版本，我想继续边开发边测试，看看有没有能持续感受到的价值或者新的问题出现。自动化测试方面，一是想把它和每日构建集成起来，将及时测试深入到每日。即使没有新版本发布给测试人员，也对老功能及时回归。二是想度量自动化测试覆盖率，虽然有新需求，但及时将其稳定在一定范围内，争取手工测试结束时自动化测试也达到预定的覆盖率。