关于软件测试的几点反思 - 关于测试团队的组织(2)

　　第二个方面，想讨论一下测试人员的内部细分。IT行业早已经是内部就开始隔行如隔山，分得非常细了。考虑对口的产品和技术形态，测试人员也有很大的差异了，比如测试通信设备的，测试Web网站的，以及测试 app的，其背景知识，工作流程也有很大的差异。即使不考虑这方面，从专注的测试工作内容上看，也有进一步的细分。我接触到的会分为四个方面：

　　1. 业务测试

　　这一部分的测试人员就是上面提到的矩阵式管理的那一类，负责具体的产品的测试和质量提升。所以这一类的人就数量上来说通常是最多的。

　　2. 专项测试

　　如果测试组织稍大，对测试的深度有更高的要求，而有些测试类型又需要比较长时间的积累，且技能有横向的共用性，那么就可能有专人来做，俗称专项。比如安全测试，性能测试等。就实际运作的情况来看，像安全测试这种看起来确实比较有必要，因为没有长时间专注的积累难以有效果。这样的专项测试通常人数不是很多。

　　3. 质量管理

　　有些地方叫QA或者SQA，就是第二篇里面提到的专注在质量数据的收集，研发流程的管理和推动等事项上面的一些人。通常放在测试部门，但是也可能放在研发管理等团队。

　　4. 测试开发

　　当整个测试的团队比较大，需要很多共性的基础的平台和工具建设，就可能会抽出一个团队专门来做这方面的事情，称之为测试开发。

　　实际中，关于业务测试和测试开发，其实有时候界限是没有那么清楚的，取决于多个方面的因素：

　　1. 老大观念

　　没办法，这个很重要。接触到几位部门级测试团队的负责人，观念不完全一样，有些认为独立的测试开发团队很重要，且愿意大的投入，有些觉得没必要有专门的测试开发团队，业务测试团队应该有能力来做测试技术方面的事情。

　　2. 业务测试团队的能力

　　这个要看实际的情况，业务测试如果要做得比较好，业务测试的团队本身也需要比较好的技术能力，所以很多测试开发意义上的事情业务测试团队也可以做，实际也在做。但是也有些情况，业务测试团队本身的技术能力不够，或者时间非常的局限。从业务测试团队本身的意愿上，肯定也希望能做一些技术方面的事情。

　　3. 测试开发团队和业务测试团队的双向互动的情况

　　一方面是看测试开发团队做的东西能否在业务测试团队落地，涉及方案本身，是否贴合项目时间，以及和业务测试团队的配合的情况。这个实际情况应该还是比较复杂的，各个团队面临的实际情况都不太一样。

　　最后想讨论下关于测试人员外包。这里不讨论整个项目的测试外包，那是另一个范畴，也曾经和一个资深的测试leader深入聊过，不过最终也只是些理论推导，没有实际的应用，很多问题也不好说。

　　自己关于外包的观念也一直在变，因为看到身边不同的实际的例子，目前的想法大致如下：

　　1. 觉得外包非常的有帮助，能帮助完成很多的测试工作，在招聘速度上也很有优势，所以是个不错的选择。

　　2. 就实际运作来看，觉得外包的比例不能太高，一个正式配1-2个外包应该效果还不错，太多了对项目，对外包同学的成长觉得都不太好。

　　在我们团队的应用中，还有几个小的实例的体会

　　1. 像面试正式员工一样面试外包

　　如果我们觉得外包只是过来做黑盒的手工测试，随便找几个人就好了，可能效果不会太好，因为最终还是取决于人。我们目前的几位外包同学都是我们非常认真的面试过，从很多位中挑选出来的，在团队里面发挥的作用其实已经超出了我们的预期。

　　2. 更放手让他去做

　　就目前项目的情况，我们的外包同学除了做好基本的黑盒手工测试，他们也可以牵头一个项目的测试跟进发周报，自动化的用例制作和问题定位，crash问题的跟进分析等，而且工作的态度和主动性非常好。因为我们没有给他们设明确的界限，只要他愿意尝试，也具备基本的能力，那就可以去做。这个和上面的1也有关系。

　　3. 关注外包同学的发展

　　这两年接触了很多外包同学，团队里有好几位正式同学也是之前做过外包，所以对外包的看法有些不同了，在职业发展上尽量和正式同学一样看待，并关注他们个人的发展。

　　在这个充斥着企业文化，价值观的年代，测试如果作为一个独立的部门，也一定会被问这样的问题：作为一个独立的测试部门，我们的核心价值是什么?

原文转自：http://blog.csdn.net/superqa/article/details/21966881