接触敏感测试也是到google上海后，原先的工作即是传统意义的测试，涉及到很多业务类的东西，自然项目上多会采用传统的瀑布型（以后会写篇对不同类型项目讨论下项目的人员组织结构）。
1、关键还是人——测试人
当我加入财经搜索项目时，并没有像我在newegg那样，新进人员的会有完整的文档甚至是视频，整个的测试流程需要测试人自己来搭建，由于开发测试比是10比1，项目交给你后，你就是为这个项目的质量工作提供一条龙服务，那么这个测试人非常重要；google的项目/产品模式都是从下往上的推动，强调个人的主动性，这个可以从gmail、chrome看出，gmail完全是20%时间做出来的项目。
2、更加强调沟通
这个和过去强调的项目人员角色清晰化格格不入，过去的项目人员各自负责一块功能，埋头苦干，沟通仅仅限于任务，而对于产品的前景、项目的发展往往抛给项目经理，因此一直以来IT人员给人的印象总是默默勤劳的，而沟通的事情都是项目经理或测试组长的事情；
而在敏捷测试里，由于资源的分配，可能一个项目就只有一个测试人员，那么他就必须和开发人员、技术经理、产品经理进行广泛的沟通，推动他们对质量的意识，更早的开始测试；甚至可以参与到产品需求及产品发展方向的讨论；所以整个团队的人员都需要有良好的沟通能力，也为后面的文档轻量化提供了条件。
3、更加强调个人能力
仅仅是黑盒测试的能力远远不够，编程能力是必须的，搭建自动化测试平台，性能测试，建立质量的metrics或dashboard提供给开发团队让他们随时关注产品的质量；甚至可以参与建立单元测试的框架，推动开发单元测试的覆盖率；google里有一个很好的项目质量认证级别，每次的升级也是对整个团队的鼓舞；同样的开发人员的能力也有新要求，上面文章提到了代码的可测试性以及Cbuild（continue build粒度比daily build更小）。
4、更加灵活自由
因为是敏捷，所以不再像CMMI那样强调流程化，每个节点都需要有对应文档， 测试计划更简洁——one page test plan，发布更频繁——bi-weekly push到weekly push，那么对应的测试用例更粒化：回归测试用例集可以包括基本手工测试用例集、自动化测试用例集、完整测试用例集（这个往往只有在整个项目改版的时候需要）；而对于新功能，前面文章中提到了diff工具，对新功能先有个评估，之后再开始测试，所谓磨刀不误砍材工。
5、不具有广泛推广的意义
可能很多人看到google敏捷测试的经验，会跃跃欲试的想在自己公司推广，特别是目前web市场的火热，更多的web项目看起来很适合使用敏捷测试，但是在你考虑开始推广敏捷测试时，请先注意以下几点：
a）你的项目/产品是以功能为主还是业务为主，如果是业务驱动型，可能测试人员数量就不会小，那么在测试的同时可能更会关注业务上的内容。
b）你的开发/测试人员个人能力是否足够强，能力上需要有个评估，例如测试人员coding的能力，开发人员对质量的认知度，否则无法“快”。
c.人员备份问题，这里说到的敏捷团队人员都比较小，肯定不超过10人（实际可能只有5，6个人员，产品经理和Engineer manager是共享的，负责多个产品），那么团队是否稳定，因为很多公司不可能提供像google那样的福利待遇，一旦人员流失，由于文档轻量化，接替人员不能在短期内接手，项目进度会受到影响。
所以虽然google在web测试或敏捷测试上有很丰富的经验，但是你还需要参考传统意义上的测试优势（微软在客户端的测试经验就非常强），具体结合你的项目来确定测试流程，自从手机智能化后，很多公司已经开始参与移动手机项目，那么手机上的测试模式又可能会有新的发展（希望熟悉这方面的朋友来分享经验）。
