现在越来越多的软件公司开始重视测试，这里想探讨一下测试人员在研发部门的组织方式，以及其对测试工作的影响。
    在一个比较正规的公司里面都会有一个组织架构图，划分出各个部门。通常来说，测试部门有下面几种组织方式。
    1. 从组织架构上独立的测试部门
    在这样的架构下，测试部门或者测试组和纯粹的开发部门是独立的。测试团队被看成是提供测试服务，可以为一个或者多个项目服务。从管理架构来看，QA engineer report给test manager（Quality Assurance Manager，QM），QM report给group QM或者director，然后上面可能就是负责产品研发的VP。开发这边的engineer report给project manager（JM，为区别于product manager），JM report给group JM，上面可能也是研发部的VP。到这个层次就合并到一起了。根据组织的规模不同，中间的层次可能多或者少。
   
    2. 归属于项目的测试部门
    在这种组织方式下，developer和QA都规属于某个项目，测试人员只专注于这个项目，而不会同时去测试其他产品。从组织架构上，都report给项目经理。这种情况下项目经理对整个项目负责，也拥有最多的决定权。   

    3. 以上两种兼而有之。
    在有些公司可能上面两种方式并存，每个项目有自己的专职测试人员，同时公司有独立的测试部门，这个部门的人会测试多个产品。可能独立的测试部门更多关注的是一些有共性的东西，比如一些系统测试，还有公司或者行业的标准。

    4. 矩阵型结构。
    矩阵型的结构其实也是一种混合。从工作的角度，QA属于某个具体的项目，并且会专注于这个项目，但是从人员管理上，他们有自己的QM，QM和JM是同级，往上和第一种情况比较类似。

    对于第一种架构，可以看出一个特点就是QM和JM处在一个级别，他们有同一个老板或者老板的老板。关于这种架构的好处，Rex Black在Critical Testing Processes中有所论述。他是从反面来看的，如果QM的老板是JM，会有什么问题？ JM的一个重要职责是保证项目按期完成。但是quality如何，其实是一个比较难以完全量化的东西，很多时候对于一些defect的review是要依赖主观和经验的。完全有可能为了schedule而忽略一些重要的defect。如果JM是QM的老板，那么作为对quality直接负责的QM，他很难把客观公正的quality状况直接反映到上面，会有一种dilemma situation。太依赖个人的专业素质是不太现实的，还是要从组织架构上给予一定的保证。 这一点不只是对QM，对engineer也是一样。
    就我目前了解的情况，第二种方式很多是在一些应用项目，或者是一些实验性的项目上面。这种项目要么是项目经理全权负责制，或者对quality没有太高的要求。
    第三种是因为有个朋友的公司采用了这种组织方式，具体的效果我没有详细的去了解。
    最后一种可能被很多公司采用，它的好处是保证了测试人员对项目的专注，同时又有第一种的人事上的独立。可能很多产品型的项目会用这种方式，因为一版版做下来需要对产品很熟悉的测试人员，而且通常schedule都会比较紧，人员也无法共用。
   
    其实这个问题就好像企业的开发流程一样，没有一个唯一的完美的东西，每个公司都会选择自己觉得最合适的，然后不断的调整。以上的几种算是被经常用到的几个模式，当然也可以混合出更多。我想关键是要看出各种方式的优缺点，然后结合公司和自己项目的特点来选择。