测试人员是否应该以技术为导向？

在51testing的blog上，看到一篇对话，里面对测试人员进行了分类，第一类是只提交缺陷的，第二类是判断缺陷发生的模块，第三类是定位缺陷并找到解决方法，第四类是自己动手，丰衣足食，不要程序员了。
原文在：http://blog.51testing.com/pcl/archive/2006/08/22/1608.html

因为个人不赞同文中的观点，就回复了一些内容，下面就是我的回复：

1.感觉文中的说法有很大的问题，会误导太多人。
不知道是否思念在外企，就是那种1天10行代码的大公司，在那里，你随便怎么玩都可以。
但是，国内太多的中小型公司，开发进度都赶的很紧很紧，测试可以说压缩到几乎没有的程度。
我经历的测试，一半给的时间是1～2周，大概5～10个工作日，40～80小时的测试时间，各种缺陷在100～300左右。
说明，没有测试用例，否则所有的测试时间都要用来写用例时间了。有时间事后可能会补充一些。

回到主题：
第一类，我发现缺陷到提交，顶多10分钟。
第二类，发现缺陷到复查，需要半个小时（把熟悉数据库、表等时间也都计算进去了）
第三类，需要1～2个小时。
第四类，已经脱离的大多数测试工程师的工作范围，可能说是调试工程师了。

理论化很容易，我也可以说出一堆的大道理，但实际情况希望各位能老老实实的告诉新人。告诉新人90％是如何做的，而不是1％的做法。

说明，实际第一轮测试时间2～4天，一般回归3～5轮。
大家可以自己算算每个缺陷需要多久的时间发现出来。
我想我这个应该算比较典型的国内中小型企业测试人员需要经历的事情吧。

作者对我的回复进行了一些反驳：

我没有在外企呆过，也没有在大公司呆过，我是从小公司走出来的！
时间短项目紧张，都是大家知道的国内情况，但是我说的是一种能力的提高,不知道你理解没有。
请看标题，手工测试到底有没有技术含量，^_^!

我刚才反复看了留言觉得有点问题，鹿鸣你熟悉系统都是在后期熟悉么？
“第二类，发现缺陷到复查，需要半个小时（把熟悉数据库、表等时间也都计算进去了） ”
虽然我原先在的公司不正规，但是我都会主动找开发人员熟悉系统，我想你也是这么做的，不会等到最后，所以你说的熟悉表的结构的时间算在发现问题的过程中这肯定是在浪费时间，大部分人都会前期就座这些事情的，其实用不了多长时间但是很见效。
“第三类，需要1～2个小时。” 不会这么夸张吧？你只要思路清晰，该做什么做什么，时间紧的时候告诉你100多个功能都要验证一遍，我想任何人都会作取舍，不会把时间浪费在找问题的原因 上边这是开发人员来做的。但是我可以做到的是在尽可能的情况下帮助开发人员更快的发现问题在那里。减少开发人员的投入。
你说的是事实，我不否认，而且你的说法我也很赞同。

我的再次回复：

我就是等到最后的，而且说实话，我也很少去看开发人员技术方面的文档，一是很少有，二是有也不全，甚至是原始版本，会对程序造成误解。
另外，我们的机器很少。我这两天的工作就是把缺陷缺陷服务器的东西倒到新机器去。旧机器是PⅡ450，年代久远到电源坏了，无法启动，换了一个电 源勉强启动起来。新机器也是旧的，PⅢ667，连80G的硬盘都不认。说这么多废话，一是表明测试的资源严重不足，二是说明，没有空置的机器安装开发软 件！！
我想测试人员应该有共识，应该用比较干净的机器测试软件吧。我曾经遇到过很多次，在我们机器的问题，在开发那里就没有出现，就是因为他们的机器有开发环境。
这样来看，第2、3两条如何成立呢？（MS只有微软、Google这样公司才会每人两台机器）。
还有，我们虽然是中小型公司，但软件都是大家伙，数据库之流都用小型机，即使安装到本机，呵呵，我的机器MS干不动那些大家伙。
我承认测试人员应该提高自己的技术能力，所以我对所有问到我的新人，都建议他们先做程序员再转测试。但测试的能力不在于帮助程序员定位错误，就我个人感觉，这是得不偿失的事情。有一个工作效率和代价的问题。
测试人员可能定位错误，但是测试人员用半个小时定位的缺陷，开发人员1分钟就知道问题出在哪里，那么这样是否测试人员的工作有意义的呢？
测试人员的职位可以分的很细（虽然现在很少有这么划分的），比如微软那些人，很多可以说是白盒测试工程师，从代码级进行质量的查找修复，那是他们 的工作；但国内因为历史、现实等方方面面的原因，绝大多数我想都是黑盒手工测试人员，而且现在这些人员的心思也都相当的不稳定，都想这当开发人员或者自动 化测试人员，但各种类型的人员数量在那里摆着呢，我想即使在国外，最后的系统测试人员还是占比较多数吧。
其实我个人认为，手工测试人员的提高，可以从业务、用例、测试方法等方面提高，未必以技术目标为转移，技术方面，无论如何，测试都不会如直接开发程序的人那么熟悉。
现在国内唯技术论的论调真的太高，影响也大，这篇也有这样的问题。
我的说法就是从实际出发，找到自己的出路，未必能找到缺陷并修改的测试人员就是好的测试人员。
好的测试人员应该是多、快、好、省的尽可能发掘出程序错误的人员。
絮絮叨叨的说了这么多，也没有一个重点，大家权且看之好了。