我们需要测试人员吗？

　　先说一个故事。

　　接手一个小项目，是因为之前的项目经理被调走了。当时跟我介绍项目情况的时候，这牛人项目经理说，项目完全没问题，功能就那么一点点，很容易搞定的。我随口问了一句，有测试人员吗？答曰，这么简单的小项目，还需要测试人员吗？我茫然。

　　这牛人于是就介绍完了，把这个当时运行很流畅的项目组交给我。每个人都把客户需要的功能做出来了，也已经拼接好了，好像我接手就是来拿做好的成果一样。

　　忘了介绍这牛人了。这牛人为什么叫牛人，是因为特能加班。每每在项目交货的时候，跟客户耗上那么几个通宵。并且，还带着整个项目组去耗。我自认没有他那么牛。

　　接手项目，并不是马上就插手乱指挥，这是我的原则。但是还有2周就要交付了，我也没有太多时间去慢慢了解项目。于是，在项目的第二天，我就去找部门要测试人员了。问我理由，答曰，没有理由，就是要2个测试人员。

　　很容易的就要到了两个PLMM。看着MM我就心里舒坦。而且两个MM之前还没测过手机项目。没关系，有测试就行。

　　熟悉了一天之后，PLMM们第二天就发现了一个很简单的BUG。简单的说，就是ListView的数据，在一些操作之后，就乱套了。本以为很简单的BUG，也就没多问了。

　　第三天，项目组成员们很紧张的忙着。第四天，还在忙。我有点坐不住了，去看了一圈代码，感觉有点晕乎。再看，猛然发现，这些代码的数据结构就不对，需要重做！

　　我的乖乖啊。这是神马啊。如果我放任这情况下去，在项目交货的时候，我也要被逼做牛人了啊！

　　还好测试人员进入的早，这BUG带来的影响，在重构代码后，终于平息下来。我们在交付的时候，没有为业务逻辑而通宵。当然，客户的硬件和框架着实让我们牛了一回。我们只是晚上在等客户解决问题的时候，打打牌而已，没有被客户追着改BUG。

　　故事说完了。“故”表示已经发生，“事”表示有这么一个经过。

　　我不禁要问，难道有那么多人，认为手机项目，就真的不要测试了吗？

　　传统业务领域，测试人员的重要性已经被大家所接受。我在做项目经理的时候，一般是偏袒测试的，因为我对他们的支持，他们才可以放心的发表不同的意见，才能把问题尽早的暴露出来。当然，也因为我的支持，测试人员经常犯错，把一些正确的当作不对的。不过，我宁愿测试人员犯错，也不希望BUG和问题隐藏到最后，到最后客户发现了，那就非要“牛”不可了。

　　测试人员 ，在传统业务领域，做的几个验证工作，可以用一个V字模型来说明。

　　1、单元测试，是对编码的验证，保证编码无误，也就是保证某个单元（可以是页面，可以是某个流程等等）被正确的编码。

　　2、结合测试，是对详细设计的验证，保证各个单元串起来之后，能够完成基本的业务流转。

　　3、功能测试，是对功能设计的验证，保证系统的各个大功能得以正常流转。

　　4、用户体验，是对需求分析的验证，保证系统就是用户想要的东西。