很长一段时间，我长期工作的环境基本都是只有我一个测试，并不存在什么test team的概念，随着团队的成长，项目的增多，意识的转变等因素，测试队伍也开始有所变化（虽然目前也只有2个人），我们在测试规范、流程、执行以及配合上都逐渐变得更加成熟，我把这些小小的改变和最近几个项目积累的经验在这里做个梳理和记录，也希望在以后的项目中有更多更大的收获。。。

　　我们团队正全面尝试从以前的“先开发后测试”到“边开发边测试”的转变，在每一个阶段性任务测试期间，我们进行的是深度测试，并且保持跟开发同步，对内建立更加快速的反馈机制，这种模式是非常有利于项目的集成测试和后期回归测试；

　　以前的测试，因为知道后续还有多轮测试而有意识地推迟某些当前就可以做的测试。而现在，通过引入敏捷测试思想而将测试用例简化为checklist后，测试组按照功能模块深度剖析，结合项目经理制定的模块优先级与开发时间进度表，完成项目测试方案和计划。这里每个独立的功能模块可分解为若干可迭代的用户故事，每天按照测试计划和checklist进行跟踪和监控，围绕该用户故事有什么测什么，并且尽量一次测试充分。从某种程度上说，就是把广度优先测试转移到深度优先测试。

　　我们在婚嫁商城、手机客户端开发第一期、4号店等项目中，均按照深度优先测试的模式执行，效果比我预期的好非常多！首先，最重要的是解决了以往项目前期或中期因设计、开发or其他不可控因素导致项目延期，将原本就不宽裕的测试时间再度压缩的尴尬情景。如今进度把控，能精细到具体的用户故事，功能模块；当在某一阶段任务的时间节点上出现了延迟问题，项目经理会想办法，尽可能协调大家的时间将延迟的工期补上，防止每个环节层层无休止延迟导致到项目后期，无法保障正常的测试时间的问题。But，尽管如此，我们还是会出现个别项目延期的情况，原因是多方面的，我们也单独总结过，还要努力啊。。。屌丝们，加油！

　　当然，这种深度优先的测试模式也有一个弊端，因为用户故事和功能模块的特性，故事间和功能模块之间是相对比较独立的，但是我们的系统却不能忽视故事间和功能模块间的内在关联。所以在我们的模块测试完成之后，在回归测试之前，必须还要进行非常关键的基于用户场景的测试，在不同的用户场景里，将多个用户故事和功能模块集成起来一起测试，从而尽早暴露故事间和模块间的一些缺陷，弥补深度优先测试的不足。

　　从去年开始，团队开始引入敏捷开发思想，或许我们至今仍然困惑着，思考着如何来落实这个敏捷。其实，刻意追求的模式未必是适合我们的，又或许我们已经在需求阶段，在开发阶段，在测试阶段已经慢慢慢慢开始有那么一点点敏捷的意识和思维了，在各个项目的执行中体会到的失落、挫败、欣喜、狂热。。。已经开始摸索出的那么一些些的经验也好，教训也罢，总之，我们成长了，不是么？