测试人员如何能够受到重视？

cleverman

常常听到有人抱怨说公司不重视测试，不重视测试人员。没错，这个在小公司是非常常见的现象。其实，即使工作在大公司，虽然测试和测试人员的地位得到了很大程度的提高，可是相对开发和PM的地位还是有一定的差距，也就是说测试在公司中的地位还是比较低的，这个其实是不争的事实。道理也很简单，测试人员的技术水平，测试工作的难易度和测试在产品开发过程中的相对地位都决定了这个现实。由于测试的性质造成了相对的地位低下，那么如果想使得自己作为一个测试人员在公司或者项目组的地位得到提高，一个行之有效的办法就是超越测试的工作范围。简单来说，一个测试人员在工作中的重要性的大小不是仅仅由测试的工作范围来决定的，更重要的是你能够在多大程度上去cover开发和PM的工作。我知道在很多很多公司，包括很多大公司，都不需要你这样去做，我也不期望很多测试人员会这样去做。可是我最近理解到，去take开发和PM的responsibility对于个人的发展是多么的重要。由于各个公司的测试情况千差万别，个人的测试发展之路也是各式各样，这里主要是谈个人的理解，很可能只适合少数测试人员。这里先讲一些事例：

1。本人以前在一个世界前几软件公司中担任team lead, title是senior SQAE，来到现在的公司是按照最低级别录用的，也就是entry level。为什么差别这么大？主要是各个公司对测试人员的要求差别太大了，这里如果只是满足测试的工作内容的话，都很难升入中级，我可见到不少水平不错，工作好几年的员工连个中级都不是呢。可是这样的员工跳到国内的公司就有做director的。

2。以前也给大家介绍过我问director测试应该如何发展，他的回答是“短期要学好C，长期还是学好C”。可见他的回答完全跟测试没关系，应该是完全是开发的范畴。

3。在一次会议上有人问director的老板，测试senior的实在太少了，如何才能发展成senior。他的回答主要是强调测试人员要更加的贴近客户，从客户的需求去考虑问题，不能局限于技术。可见他强调的又是PM的范畴。

4。自己的老板对自己提出的要求也是完全超出了测试的范畴，基本点如下：

Debugging: find root cause of a bug （开发）
Code review （开发）
Answer customers' questions (PM)
Researching competitors' products and showing options in functional spec (PM)
Don't only focus on my components, responsible for whole feature
5。一个印度PM同事就很牛，工作就是超出PM的范畴，开发的东西他知道底下具体是如何实现的，出了什么问题他都能估计出可能是什么问题。测试的设计他也能提出很多好的建议，很多测试的case也得请教他。他就升的特别快，几乎一年至少一级的往上升，最近发现都senior了。

以上的例子只是想说明作为一个真正出类拔萃的测试人员各方面的功力都不能少。很多人还在争测试，开发的地位高低，水平高低。其实对于高级的测试人员和高级的开发人员来说，他们的技术视野都应该是比较一致的。因此，如果作为一个测试人员真的想提高自己的地位，就不要把、开发和测试对立起来，要把他们融合在一起才对。最后想说的是，能够把这些都做好的人不会太多，那个印度PM也算是很少见的了，他是真的很努力，负责。我本人以前也习惯性的局限在自己的任务范围之内，看到是其他人的工作就不管了，幸亏得到老板的指点，最近无论是什么问题，只要是跟自己产品相关的都积极主动地去关心，思考和处理，感觉进步很大。也希望能尽快的达到老板的要求，就是“只要是这个产品的问题，别人第一时间就会想到去问你”。我想这个时候，自己的重要性也无需争辩了。

以上是一些个人心得，不知道是否对大家有帮助。

dujun

多学一点是没有害处的

afeng

一定要有code能力,把自动化测试程序写出来,看哪个开发还敢看不起

happyeveday

不是谁看起谁的问题,是从各个方面提高自身的问题,coding算一方面

chech28

既同意又不同意：）
内容是赞同的，不过，我不认为以下这些不是QA的工作
Debugging: find root cause of a bug （开发）
Code review （开发）
Answer customers' questions (PM)
Researching competitors' products and showing options in functional spec (PM)
Don't only focus on my components, responsible for whole feature

这些东西在我看来本来就是QA的范围

cleverman

那你们对QA的要求也够高的。实际上一般的QA job requirements上，你是看不到这些东西的。你们对QA还有什么其他要求吗？

afeng

这是小公司项目经理的职责,大公司绝不可能有人一人兼这么多职

cleverman

原帖由 afeng 于 2008-4-9 14:52 发表
这是小公司项目经理的职责,大公司绝不可能有人一人兼这么多职

也不是要全兼，只是测试的尽量去做额外的工作，提高自己的经验水平和对team的影响力与贡献。不过话说回来，全兼也不是不可能的。最近几个月由于人力不够，整个feature就我一个人负责了，pm, dev都没了，所以要负责很多pm和dev的职责了。我觉得虽然这种情况很少见，但是如果遇到，测试人员能够真正顶起来，也不错。

happyeveday

你说的1,3点我也在做

afeng

遇到是要能顶起来,但我一般不会主动去兼,嘿嘿

cleverman

原帖由 happyeveday 于 2008-4-9 15:03 发表
你说的1,3点我也在做

1,3我以前也在做。现在目标不一样了，对于1，我希望发现每个bug都能locate source code，至少是自己feature的source code，其他feature或team的就算了。因此，需要对自己feature的source code非常熟悉才行。因此2就很重要了，当然我是希望慢慢的积累。以前发现bug如果没时间就直接扔给dev，或者debug不出来就不继续了。对于3，以前大部分的回答都是靠pm来做，自己只是回答跟测试相关的，design方面的就不敢说话，现在无论什么问题都要尽量回答，即使自己不会的也要搞清楚是怎么回事。总是是花费了大量测试以外的时间，不过进步到是也快。其实一般的公司对测试的要求只要能保证重现bug就基本足够了。
你是用windbg吗？kd用不用？

cleverman

原帖由 afeng 于 2008-4-9 15:10 发表
遇到是要能顶起来,但我一般不会主动去兼,嘿嘿

就剩自己一个人，不管也得管呀。才测试这个东西一年，现在竟然都成员老了，以前的人都走光了。

happyeveday

呵呵,至于自己去代码里去DEBUG,这个有难度
1 需要大量的时间, 2 需要对需求有准确的把握,3 需要对你所测系统的表有清晰的了解
至于设计方面,我是不懂的,但也不排除有些PM也有犯错的时候,我见过有些查询的SQL一屏都显示不下的,关键是自己看后觉得没必要关联那么多,但到了这个时候再说什么也是没用的

cleverman

原帖由 happyeveday 于 2008-4-9 15:45 发表
呵呵,至于自己去代码里去DEBUG,这个有难度
1 需要大量的时间, 2 需要对需求有准确的把握,3 需要对你所测系统的表有清晰的了解
至于设计方面,我是不懂的,但也不排除有些PM也有犯错的时候,我见过有些查询的SQL一屏都 ...

是需要花大量的时间，尤其是自己对系统不熟悉的时候。另外熟悉debugger也是需要时间和经验的。但是，很多测试人员转成开发人员就是这么走过来的。不少都是因为dev走了，而测试人员熟悉代码就直接转成dev了。

happyeveday

哈哈,看样子我得快点走了,要不然再过几天我就成为你说的那种了,但不是因为DEV要走

afeng

你们公司流动也这么大?老美也喜欢跳槽,呵呵

cleverman

原帖由 afeng 于 2008-4-9 16:09 发表
你们公司流动也这么大?老美也喜欢跳槽,呵呵

总做一个产品觉得没意思吧，再说他们水平高，想去哪里就能去哪里，是为了兴趣而工作的。走了再找人填补可就难了。我们这里长期缺少dev，manager要亲自fix bug。
不过主要还是公司内部的transfer，而且最牛的两个也不是老美，是印度人。

milklybaby

今天刚刚跟一个top 1的公司里的TESTER聊天，讲到不同的测试工作的分类，他们大体分四类，有负责培训的，有制定规范的，有项目中实施测试的，另一类我忘记了。每一类职务都有在技能方面的侧重要求。
如果做不到全能，至少得做到专业一项，这是我的看法。

afeng

看来印度人牛啊

archonwang

同意楼主的说法，这是一条漫长艰辛的道路。但是只要能通过这条道路，你将比一般开发人员更有话语权。

有人说起过关于自动化测试的话题，我的感觉是如果所在项目的规范做得较好，文档比较齐全，自动化测试是趋势，但是一脱离这个前提，自动化测试则可能就是空谈了。我见过实施自动化完全失败的例子——盲目实施和引进，结果不仅没有效果，还耗费了大量人力财力。

关于测试的领域。既然是边缘科学，那么沾边的都必须有一定的认识和了解。一件事情如果做得时间久了，可能会变得麻木，这样就必须要扩展和深入其中沾边的内容，比如开发流程、设计、需求获取、变更控制与流程管理等内容。一件工作一次做好很容易，难的是每一次都比前一次有提高。

希望大家可以看到方向，不必迷惘和失落。