为什么互联网公司不开除软件测试工程师？

我尝试从几个角度来分析，在正式分析开始前，我们先把范围划定在软件开发这个圈子里头，并且对这些问题进行解释。关于这方面的讨论，一般会存在以下几个误区：

• 将开发阶段、测试阶段完全剥离。
• 对测试的理解有些偏差，误认为测试只是在产品做出来之后，使用它，然后挑毛病，找bug。
• 误认为测试只有功能性的校验。

下头对这3点逐一解释：

将开发阶段、测试阶段完全剥离。

经常有人会问，“为什么互联网公司不开除测试，转而让大众来测，找到一个bug给100元？”

这个问题有个假设，就是开发阶段、测试阶段完全剥离开了。开发阶段单纯地就是开发人员敲代码，然后出来的东西交给测试人员去做测试。我不否认，现在依然存在这样的实践方式。但是，这不是一个好的方式。因为这种流程，把发现bug的时间点推迟了。而发现bug的时间点越靠后，修复它所要付出的代价就越大。

这点应该很容易理解，比如你敲钉子，如果一口气敲完了才发现，敲歪了，那就得拔出来重新来，可是东西上已经有一个很深的洞了。所以，好的方式是敲一敲，检查一下，随时纠正方向，确保前进的大方向是正确的。

软件更是如此，某个bug可能是在最底层的地方发生的，如果早期发现，定位也容易，修复起来被牵扯到的地方也少，付出的代价可以接受。因为bug的产生可能是多个原因，有可能是功能性的，也有可能是对业务理解的偏差导致开始就做错了。

如果在产品做出来，发布给最终用户之后才发现。那个时候再排查到底哪里出了问题，就不是一时半会能做到的了，代价很大。

所以比较好的实践方式，是由专业的业务人员把要做的东西切割成足够小的、彼此独立的、可单独交付的模块，开发、测试以及业务人员及时沟通、及时反馈，一个一个小模块完成，随时做随时测。把发现bug的时间点尽量往前推，这样就可以把修复它的代价降得尽可能小。

当然，小模块都通过测试，并不意味着所有小模块拼装起来组成的系统一定正确，还需要进行层次高一点的集成测试。这就引出了第2点。

测试就是找bug的？

对测试的理解有些偏差，误认为测试只是在产品做出来之后，使用它，然后挑毛病，找bug。

有这样的偏差并不奇怪，因为执这样想法的人太多了，甚至包括一些软件行业的从业人员。比如有这样的说法：

开发就是敲代码的，测试就是找bug的

原文转自：http://news.hiapk.com/internet/s591fffb7e712.html