问题：

　　在学校的时候，老师说女生以后如果从事不了开发，可以去做测试，有次面试，我问在公司一般程序员未来几年的发展，他说看个人能力发展，如果水平差点可以去做测试。

　　精彩答案：

　　pansz：

　　水平差的开发人员，其绩效是负的，意即不但自己没有产出，还需要耗费其他人的时间帮他解决问题。意即为了解决他写的代码相关的问题会拖慢整个团队的进度。

　　但是水平再低的测试人员也不会出现负绩效。最多是没绩效而已。所以从leader的角度，如果没把握这个人能达到开发的门槛，去做测试是个更稳妥的选择。

　　如果是回答楼主的问题，那么到这里也就差不多了。因为这就是现实。至于这个“现实”是不是合理，这种“现实”是否需要改进，那么就请参见其他人的回答了，因为我觉得吧，现有的情况，在实际操作中很难保证把优秀的测试人员留在岗位上。你给钱太多了人家赚点钱就自己去创业，给钱少了人家想办法升职，升职完了就又脱离测试岗位了。——测试人员创业的可能性甚至更大，因为他更了解需求层面。

　　陈甫鸼：

　　现实地说，我得承认@pansz 的看法很有代表性。我所知的很多公司的看法都是这样。但这不是我认同的看法。水平差点可以做测试，实际上就是把测试部门当作垃圾收容所。但是实际上说这些话的人，我相信并不理解测试究竟是什么。

　　如果我们不打算做深入的分析，其实要驳倒这个所谓的理论只需要一个例子就可以了。很多程序员不是总喜欢用架构来形容程序么？架构这个概念来自建筑行业。可是我相信很多人都知道建筑需要专门的人负责质量管理的，也就是保证交付建筑的质量满足需要。我们不会允许建筑公司自己做完工程自己验收然后直接交付使用的。我们都知道测试本身存在的目的是为了保证软件的质量满足需要，那么为什么乐于用架构对比软件的程序员们却认为软件可以不需要测试人员？显然这是荒谬的。

　　当然，我知道这种对比是驳不倒骄傲的程序员们的。我们从数学家那里继承了高傲的本性，天真地自以为算法就是一切（当然，他们中间的许多人其实多数时间用的算法都不曾超出过大学二年级那一年的课覆盖的内容），却不曾真正接受工程师的严谨。所以我们还是需要详细的分析。

　　首先，测试是什么？保证产品质量，这个过于模糊的说法说明不了问题。最直接的方法就是数一数测试究竟需要做什么：

　　1、监控产品流程。从时间控制的角度来说，开发新功能和修bug是一个平衡。开发得太快就可能把交付给下一个阶段一个问题较多的版本，从而使得后面的问题更难处理。我们如何知晓每个阶段软件质量怎么样？具体的方法很多，回归测试，代码覆盖、压力测试等等。但是这些信息谁来收集和分析，怎么分析？能得出什么样的结论？有多少程序员会自己做这些？

　　2、搭建复杂的应用场景。谁能知道测试一个完整的Active Directory服务器的回归测试环境需要多少台域控？我搭建的纪录是11台，还不包括中间可能动态加入和删除的客户端。其中包含大量故意的毁坏性操作。每一次毁坏之后都必须恢复现场进行下一个测试。有多少程序员构造过这种场景？

　　3、简化问题报告。当发生用户报告时，他们最初给出的步骤往往过于简化或者过于繁琐，缺乏直指问题所在的步骤描述。很多时候由于步骤不清楚，导致分析过程中存在很多弯路。这个时候需要有一个人来不停地和客户打交道并定位关键步骤。这个步骤总是必须完成的，那么谁来处置？有多少开发人员真正负责处理过这些？

　　当然我知道很多程序员们会高傲地昂起头：这些我们都不需要。只要我保证每个函数是对的，最后的软件必然是对的，所以只要单元测试就够了。这种理论我不止听一个人说起过了，也实在是没法说清楚。我只能说这些信息是有很多人需要的，既然有人需要，就得有人做。

　　我承认，有些情况下我们确实不需要专门测试。这种典型场景实际上有一个很简单的前提，即软件本身不包含复杂的应用场景。比如单机软件，比如单服务器网站。但是这不包括那些本身需要复杂使用场景的软件，比如Exchange、比如Active Directory。这类包含集群和分布式要求的软件系统不是一个人花一个小时坐在一台电脑前试一试就能做好的。