鹿鸣：

　　按照标准的开发流程，任何不经过测试的产品，都不能发给客户。

　　没有测试部门的确认，软件产品的质量问题由项目组负责，测试部门不承担任何的责任。

　　如果开发部门不支持测试部门的工作，测试部门有权利不测试产品。

　　“测试人员不了解客户需求，测试工作无法把握重点。”这个问题问的很好，每一个测试人员对此都会迷茫，主要是时间和经验的关系，小软件好把握，但大的系统，如果没有经过系统的培训是很难了解软件过程的。所以真正测试行业软件的时候，都需要有相关行业经验的参加测试小组或做为顾问。测试小组也需要进行一定 的培训。（我测试过很多比较大的家伙，了解那些东西就要花费很长的时间，实际很多的项目，测试3、4次才知道里面的东西具体是怎么运作的）。

　　上面是测试部门的一些事情。下面说说管理方面的。

　　在实际过程中，测试部门一般都比较的弱势，除非公司特别重视产品的质量。很多的时候，留给测试的时间都不够，在软件行业的都知道，项目很少有按时完成的， 基本都会拖期，这个时候影响最大的其实就是测试。如果客户急着要，即使产品没有经过严格的检验一般也都发出去了。

　　项目经理的责任就是严格的掌握开发时间，了解客户的需求，和测试部门进行协调，准备好一切测试部门的相关资料。（现在程序员都在赶进度，基本没有文档，所以在测试前写测试用例是基本不可能的，反正至少在我工作过的公司，无论是程序员的设计还是测试人员的用例等，都是事后补的，这是没有办法的事情）。

　　在很多的时候，测试部门可以说是代表客户利益的，但真正成熟的软件公司，分工都很详细，比如有专门的需求设计人员，负责和客户打交道；还有专门的售后服务技术支持人员；通常测试部门只负责产品的质量，不会和客户发生关系。

　　AlexLJM：

　　在很多的时候，测试部门可以说是代表客户利益的，但真正成熟的软件公司，分工都很详细，比如有专门的需求设计人员，负责和客户打交道；还有专门的售后服务技术支持人员；通常测试部门只负责产品的质量，不会和客户发生关系。

　　我们公司以前就是这样做的。可惜在定位一些问题要不要改善的时候，经常要经过一个流程才能反馈回结果，有时候这个结果根本就不符合我们的需要。后来痛定思痛，决定减少这个流程。

　　鹿鸣：

　　测试部门测试完毕签字确认后，实际就已经和项目没有什么关系了。除非有太大的质量问题出现，表明是测试部门的责任，这个时候会由公司给予测试部门相应的处罚，与客户或项目组无关。

　　至于客户的问题，应该有技术支持人员（通常由开发人员兼职或转职）解决。

　　技术支持人员解决不了的问题，如果原项目组还存在，反馈给项目组；项目组解决不了的，就告诉客户下一版本解决，能拖则拖，拖到客户忘了为止。

　　如果项目组不存在，而问题真的很多，客户还必须使用这个软件。那真是太好了，赶紧重新组织项目组，开发2.0，又能挣一笔钱，哈哈。

　　AlexLJM：

　　技术支持人员解决不了的问题，如果原项目组还存在，反馈给项目组；项目组解决不了的，就告诉客户下一版本解决，能拖则拖，拖到客户忘了为止。

　　如果项目组不存在，而问题真的很多，客户还必须使用这个软件。那真是太好了，赶紧重新组织项目组，开发2.0，又能挣一笔钱，哈哈。

　　ericzhangali：

　　同意楼上两位说的流程。但是感觉目前的情况是把测试工作划分一部分到客户的相关部门。客户认同的方式似乎就是发版本给他，他测试，提交bug list和修改意见，修改后再发给他，他再测试。。。直到他满意，这里面的一次次release我个人觉得不是很正式。在时间压力大的时候或改动很微小的 时候，这种不是很正式的release是不是一定要送测，在VSS上打label，然后得到一份不是很关注的测试报告呢？因为同时版本也已发给了客户，也 许很快，客户也反馈了报告。

　　往往有一个现象就是客户提交的bug list和测试部门提交的差别很大。倒不认为这是alpha和beta同时进行。

　　这种方式确实测试部门不承担责任。由开发部门/人员承担。

　　至于测试人员了解需求的问题，情况是，对每个客户，产品的功能大致是相同的，测试人员也是比较了解的，也有老手写好的full test用例和simple test用例。但每个具体的客户可能外观要求不同，有的功能细节有不一致，甚至不同客户关注的问题点也不同。我是指这个情况测试人员不了解，这个情况只有 直接和客户联系的开发人员了解。但开发人员又没有太多时间跟测试人员详细说。

　　如果把窗口转移到测试部门，不知道客户会不会有意见。他们可能更希望和直接的开发人员联系，提出需求。