这两天部门内部在讨论全功能团队的相关东西，希望后续能慢慢的实施起来。这里全功能团队的概念，简单来说就是希望能够减少团队的规模，加快产品交付的节奏，类似于敏捷开发模式中的小步快跑，能够频繁的有版本上线运行。总体方向来说是好的，这套东西很多互联网公司也玩的很顺畅，但是在华为，最起码在我所在的部门内，还非常缺乏这方面的积累和氛围。整个研发的运作模式和管理层都是从传统的运营商转型过来的，团队庞大，低效，笨重。。。等等一系列的缺点。
关于这种团队模式的优缺点，如何根据自身的项目实际来运作，以及在这种模式下工作带给测试人员的变化和挑战，感觉部门内部普遍都还缺乏清晰的认识。昨天晚上讨论的时候，面对大家的质疑，测试经理显得有点控不住场面。今天整个部门的会上，当部门领导问到测试人员对于这种模式怎么看时，我们的测试经理也是支支吾吾，没有一个清晰明确的答案。
说说我自己心中理想的团队模式吧：
1.团队的规模一定要控制，个人感觉二十人以下是比较合适的，再大就不好控制了，而且这些人一定要坐在一起工作，彼此间应该是一站起来就能看到对方的距离。随着人数的增多，人与人之间交互，沟通，协调的成本会急剧上升，有一个著名的曲线图是这么画的，开始随着人数的增多，研发效率会有一个上升，但到了一个临界点后，效率不但不会上升，还会下降。这一点在自己的工作中也是深有体会，看着人增多了，其实带来了很多低效的问题。
2.这个团队的外部环境一定要简单，团队内部对于主要目标有自己的掌控力和绝对的自由。我们现在的研发团队，经常受到很多外界因素的干扰和冲击，什么配套软件要换了，临时需要赶个进度加个需求，设计方案出现变动等等之类的。一旦进度完不成，最简单的方法就是加人和加班，很多时候在疲于奔命，很难想象这种环境下能够做出好产品。一个优秀的团队，内部应该是轻松又有激情的工作氛围，团队有自己清晰明确的目标，不能受外界过多因素的干扰，简单的说，就是要聚焦自己的目标，而不是被外界的进度驱赶着前进。举个简单的例子，10个人需要干三个月的任务，不是三十个人一个月就能做完，这两者之间绝对不是相等的关系。
3.团队内部有快速清晰的信息共享和反馈机制，对于用户的反馈和需求能够第一时间获取到，有快速的决策机制，对于问题能够快速形成结论。
4.团队成员的能力和职责，这个话题就比较广泛了，无论多么好的流程，总是要依靠人去实现的，团队成员的能力是最重要的。作为测试人员，我一直在想的问题是，在这样的团队模式中，测试人员的定位是什么？测试人员能够为这样的团队带来什么帮助和价值？
相信做过测试的都会有这样的感觉，时间长了感觉真的是挺无聊和枯燥的，整天对着页面点啊点的，开发人员也不重视，总是带着种鄙视的眼光看待测试人员，长此这样下去，能有什么发展呢？对于这种情况，我想起了以前看一个测试牛人博客里写的一句话：“没有哪个职位鄙视哪个职位，只有能力强的鄙视能力差的”
仔细想想，测试人员相对于开发人员，优势在哪里呢？对于业务的理解能力，思维的缜密程度，问题的敏感度，这些都是优势。除此之外，我认为技术的提升永远都不会过时。测试设计思路，场景分析能力，用例设计方法，测试框架，测试工具，这些是测试人员的知识结构，除此之外和开发人员同样的，代码阅读和编写能力，算法，数据库，网络协议等等，这些知识和技能不管做什么职位都会用的上。同时也会拓宽发展方向，帮你赢得别人的尊重和认可，不管是和人沟通还是跳槽都会多一份底气。
再回到一开始的问题，在这样的全功能团队模式中，测试人员的比例会下降（按照今天会上的说法，开发和测试的比例是5比1到7比1），但是我认为这不是简单的减少测试人员（如果只是简单的减少测试人员，那我认为这种模式注定会失败的）。比例下降应该是专职测试人员的比例会下降，而不是测试工作重要性的下降。开发人员需要有测试软件的思想和能力，同样的一部分测试人员需要进入开发团队，承担起编码的工作，提供单元测试用例，帮助开发人员写单元测试代码，对核心代码做白盒测试，构建团队的自动化测试框架，编写自动化测试用例，帮助团队编写测试工具，甚至承担一些开发的工作，这样就会出现一个新的角色，测试开发工程师。这种角色的成员最好是测试人员出身（当然也可以是开发人员，但需要具备测试的思想），同时又具备和开发人员同等的代码编写能力，这种角色在业界已经很普遍了，我记不清是在什么网站上看到的，google里的software test engineer这个职位干的就是这些事，他们绝大部分时间都是和开发人员一样在写代码。我认为这样的定位，是全功能的团队模式中测试人员真正体现价值的地方。而保留少量的专职测试人员，从用户的实际使用场景出发，对系统做整体的集成验证。
这样的话，就要求团队成员都具备独立的特性设计，开发，测试的能力，对于习惯了之前的研发模式，尤其是对于测试人员，是一个不小的挑战，但同时也是一种解脱。关于这个变化趋势，以前在51testing网站上看到的一篇文章做了一个很形象的描述，大概是“替，教，帮，融合”这样一个过程：
替：就是我来替你测试，替你发现问题，我们团队现在就停留在这个阶段，测试团队要把所有事情收尾，落个吃力不讨好的结果；
教：就是我来教你怎么设计用例，怎么做单元测试。当然这里的教是相互的，测试人员也需要从开发人员那里学习怎么把需求分解为模块级别的类和函数，怎么实现编码，这个难度往往更大；
帮：到了这个阶段，原来的测试人员和开发人员就可以一起工作了，一起设计代码逻辑和测试用例，一起完成编码和单元测试；
融合：这个阶段全功能团队的雏形就已经形成了，没有严格的测试和开发的区别，当然团队内部仍然会保留专职的测试人员。这个融合其实也是分解的过程，原来的测试团队会分解成两部分，一部分在完成上边这些能力的积累和提升后进入开发团队，一部分则会做一些专项测试，例如性能，安全等，以及做基于用户场景的集成验证。
所以这其实是个挺有意思的过程，测试团队和研发模式的发展，最终目的就是把测试团队分解融合掉。。。。
我心中理想的运作模式应该是这样：团队全体成员一起分析需求信息，能够确定出清晰的目标和计划，争议问题快速形成结论，TDD思想能够在编码中真正实施，开发人员编码时单元测试能够覆盖大部分代码，测试人员具备代码审视和白盒测试的能力，缩短BUG的发现和修改周期，绝大部分低级问题能够在编码阶段发现解决。有成熟的自动化框架和明确的接口文档，冒烟测试和回归测试绝大部分依赖自动化用例完成。关于自动化测试，我的看法是：自动化是手段而不是目的，普遍的观点是自动化只能发现20%~30%的BUG，其他的都是要依靠手工测试来发现的。我认为自动化测试主要的目的是“验真”而不是“验伪”，即证明软件的功能（主要是已有的，基本的功能）是正确的，而不是去发现软件的功能存在哪些错误，因为自动化在“验伪”上的作用确实有限，无法代替人工。当然，如果功能实现后能够直接通过自动化验证是最理想的状况，但这种情况依赖的外界因素太多，例如需求是否明确，文档是否详细准确，编码是否非常规范等等，在实际中很难满足。大家都希望能够第一时间对代码进行测试，但这项任务应该由TDD的思想和单元测试来保证，而不是由自动化保证。
最后说说测试人员的发展，其实在前边已经涉及到一部分了，不管做什么职位，技术始终是最重要的。如果是因为不想写或者不会写代码而去做测试，那我觉得还是不要做软件了，换个行业也许会更好。。。。做测试不是不懂技术，不去学习的借口。软件测试有很多专门的分类，黑盒测试，白盒测试，自动化测试，性能测试，先有一个扎实的基础，每个专项做精了都会有个不错的发展前途。就我自己而言，基本上这些分类或多或少的都做过，以后的职业发展，我个人是比较倾向去做测试开发工程师的，单纯的黑盒功能测试做久了是挺没意思的，再往后会争取向着测试架构师之类的角色努力吧。