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

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也算是很少见的了，他是真的很努力，负责。我本人以前也习惯性的局限在自己的任务范围之内，看到是其他人的工作就不管了，幸亏得到老板的指点，最近无论是什么问题，只要是跟自己产品相关的都积极主动地去关心，思考和处理，感觉进步很大。也希望能尽快的达到老板的要求，就是“只要是这个产品的问题，别人第一时间就会想到去问你”。我想这个时候，自己的重要性也无需争辩了。

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

liyf51

哦 ，谢谢楼上各位兄弟姐妹的指引，看来本人得努力拉！ :

shuangpu56

哈..........

happyeveday

原帖由 cleverman 于 2008-4-23 14:03 发表
windbg就是windows debugger用来debug用的。
如果kernal mode就要用kd。
你可以在网上download

哦,下次下一个试试看.谢谢啊

jaunty

我觉得clever说的是现在测试进步的一个趋势
是不容忽视的
我现在就是遇到职业瓶颈
面临的就是技术和这个学历的问题
我也是深刻的认识到这个问题
正在从各个方面弥补自己的不足

cleverman

windbg就是windows debugger用来debug用的。
如果kernal mode就要用kd。
你可以在网上download

happyeveday

这几天有得闲,翻贴,呵呵.
至于测试人员怎么得到重视,这些问题我想不用问别人自己想想都能答出的.
但至于怎么提高自己,我想这个就看自己了,比如和开发人员多交流,有时可以看他们写代码什么的...有时我没事的时候就这样的,因为他们数据库没我清楚所以就坐他们旁边看DEBUG嘛,呵呵,看几次就摸清了,不懂的就问,没什么.所以有时候我也会直接去代码里改BUG,做报表,所以这段时间自己又有长进,呵呵
CLEVERMEN说的WINDG是什么东东啊,貌似没用过

chech28

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

全兼比较少见，但也不是没有 - -
其实CM说的那些都是交叉职责，不仅属于哪一块的职责，都和QA搭边的。

chech28

原帖由 cleverman 于 2008-4-9 14:46 发表
那你们对QA的要求也够高的。实际上一般的QA job requirements上，你是看不到这些东西的。你们对QA还有什么其他要求吗？

job requirements 上是没有这些的，但是你会遇到这些工作。
好比说code review，一般不用做，不过遇到dev忙，如果你有时间的话就可以自己去弄，然后反馈过去。
customer嘛，我们这个东西比较大，很多internal customer，我们经常要handle这部分。
debug也和 code review差不多情况。
另外我们还经常要做infrastructure的工作，虽然有专门的部门的，但大多数人还是喜欢自己学来弄，方便省事。

对于这些交叉性的职责，一般都是看你自己，并不是责任，不过大多数人都会作些的，公司一般并不特别鼓励，但也不反对。

afeng

自动化测试是要根据需要引进的,看你现在的项目测试中哪些方面需要自动化测试来提高工作效率,但也并不一定所有的测试都用自动化,我还是觉得自动化测试在某些方面代替不了手工测试,就象手工作出来的工艺品永远比机器作的要值钱

archonwang

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

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

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

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

afeng

看来印度人牛啊

milklybaby

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

cleverman

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

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

afeng

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

happyeveday

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

cleverman

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

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

happyeveday

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

cleverman

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

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

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用不用？