问题：

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

　　精彩答案：

　　pansz：

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

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

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

　　陈甫?：

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

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

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

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

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

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