TA的每日心情 | 奋斗 15 小时前 |
---|
签到天数: 3638 天 连续签到: 90 天 [LV.Master]测试大本营
|
在csdn回答一个问题的过程中,我和一位叫可战的网友发生了冲突,我个人认为他的一些观点有问题,对测试人员的态度不够友好。不过最后我们经过几轮的回复,发现是一些环境和地位的不同造成的误会,大家的实际情况是否和我们两个有类似的情况,欢迎大家进行讨论。
原帖地址在http://community.csdn.net/Expert/TopicView3.asp?id=3867252,看最后的部分就可以,我转载的也只是最后的内容。
下面的内容经过部分的修改和整理。
doer_ljy(可战):
我测试没做多长时间,一年多的测试负责人吧,后面就是项目控制的时候做过结合测试。肯定不如你经验丰富。
我们这里所有的测试都要有文档,测试数据。
我不是贬低你的工作,可是你那样实在没有效率。也没有办法很好的保证程序的质量。
也许我太理论化了,不过几十个人合作没有文档简直是灾难。这一点却深有体会。
同时,我不喜欢你的工作态度。这样好像没有办法让别人信任你的工作结果。
不过你说的测试时间不足等等,确实存在。有时会很严重。
但这个问题可能是你们PM需要解决的吧。
在时间紧的时候有些做法可以谅解,但是不能拿出来作为理论讨论是吧?
pyp(鹿鸣):
理论是理论,实际是实际,理论方面我看的应该也不少了,还有各个测试论坛也常去,但大家说的都很好听,但实际至少在我们这里用不上。
所以我这里说的只是经验而不是理论。
虽然你做过测试,但看来对测试你并不很满意,否则就不应该用那种口气说话。
不清楚你说的测试文档和测试数据说的是什么,即使再好的文档和数据,也只能起一个指导的作用,真正发现问题的还是干活的人。
我并不认为我的观点和想法有什么问题,文档我也写,测试计划是我们经理写,但用例和总结基本都是我写以后我们经理进行确认。
也许是因为我们的规模小,所以并不很正规,但实际就是实际,我不会用好听的理论去告诉别人,我只会说我的经验而已。
对于测试人员辅助开发的想法,一直都存在,最新的《测试员》上面也说到了这个问题。
我个人不是很赞同这种观点,本来也想写东西进行反驳,但后来看到有人说的已经很好了,下面是一位叫“叶子”的朋友的回复,观点我完全赞同。
叶子的话:“非常赞同前面‘不要给开发建议怎么改错来限制他的思路’。这个很重要,而且,实际中也碰到一些,毕竟测试人员对程序构架及内部结构没有开发人员那么熟悉,比较有深度或关联比较复杂的bug,测试人员其实是很难定位到的,而测试人员能够定位到的,也不过是些相对独立或简单的问题,而这些问题开发人员是很容易定位到的。(这并不强调测试人员水平不如开发人员,只是强调,测试人员对内部结构和关联并不清楚),所以并没有起到太多作用。这样做除了限制开发人员的思路,还有比较大的一个负面效果是:容易引起开发人员的反感 -------他会觉得你有点指手划脚的意思,当然如果某次定位正确了,他没什么话说,但如果一旦定位错了,他就有我刚才提到的想法了,几次不正确的定位描述下来,很容易降低开发人员对测试人员的重视和信任。也有同学说,开发,测试是一个整体,应该协调合作,不分彼此。。。。。这话我觉得对一半,错一半,作为一个项目团队来说,的确是一个整体的,需要协调合作,但并不意味着就不分彼此,否则也就不用分职责分类了,所谓的协调合作应该是各尽其责任,而不是不分彼此。虽然目的一样,但责任还是不一样的,工作重点也是不同的。---------为了累计经验,比较有意思的bug,测试人员自己可以定位,自己记录,等开发人员回复之后,看看跟自己当初的想法是否一样,长期积累,也许以后碰到类似的问题就可以提点有建设性的意见了,也能让别人信服。所以我的建议是不太确定的就不要轻易给定位了,如果能明确当然定位最好了。
无需定位问题,并不等于测试人员发现问题就一锅端上去,描述也不是越多越好,有时候可能操作很多步骤或输入很多内容后出现某个bug,但真正引起bug的却只是其中一步和一项内容不对,测试人员要做的应该是,尽量精炼步骤和输入内容,找出那一条,精准描述问题是对开发人员最好的帮助。”
doer_ljy(可战):
声明一下我对测试的态度。我自认从未对测试工作有过任何偏见。不知道我的发言中哪一点让你觉得“看来对测试你并不很满意”。我觉得这里面有一个问题,就是看问题的角度。从工程的角度(我在这里说的也是经验,既然你并不喜欢谈理论,我也不再谈理论。虽然我一直认为理论不一定都是无聊的人编出来骗人的),任何一个项目管理者都虚妄自己的项目是:有序的、易于调整的、可评估的。这首先需要项目进行的计划足够细化,这个细化的程度,我个人认为是一个最小的可评估单位。一个项目经过几次划分,最终成为若干个这样的单位。对于每个单位,我们有它的设计者、实现者、质量保障者。他们各司其职,但协同工作。那我我们如何保证“质量保障者”的工作质量呢?从项目管理者的角度,两点:一、他必须有完备的测试计划(这里包括测试者自己编制的、以及从设计者那里引用的若干文档)。二、他要有准确的测试实施报告。这两份东西都是可以评估的,同时具有责任的约束力。你提到的前面提到过测试人员自己的发挥,我的感觉很有效但是不保险。也就是说我不能靠测试人员的即兴发挥来保证我的系统的质量和稳定性。因为里面有太多的不确定性。比如测试者经验会参差不齐,比如他们的技术能力和对BUG的预见能力不一样,甚至他们的心情等等。我相信他们能做好,但是这不能作为我保证自己系统质量的手段。
写到这里我忽然有点明白PYP为何觉得我“不尊重” 测试者了。的确,我的口气可能有点重了,但是不是对测试者而是对软件工程(这里不是指软件工程理论,而是指它本身)不重视的人。任何事情,想要完成好必然要有他一套成型的方法和思路。不只是软件测试,简单一点,一块饼干我们测试质量是否合格首先要做什么?无论是厂家还是食品监督局,他们检验者有自己的标准和检验流程。你说他们是通过流程和方法来保证的质量还是通过人来把握的质量?对于一个工程,我们要努力作的是弱化个人在其中的作用,而强调团队和科学管理。我们中国软件业铺天盖地,却难成大气跟这个很有关系。谁都喜欢英雄力挽狂澜,但是在“没有英雄的年代”我们不是还得好好的活下去嘛。
然后关于“辅助开发的想法”的问题,我觉得可能是个误会。你说得挺好,我觉得也是应该做到那一步就足够了。我觉得让测试人员帮开发人员发现“BUG是在哪句代码里出现的”这事儿是万万不能的。毕竟大家各司其职。如你所说的,提供线索也就足够了!
最后,有个有点失礼的问题:你所在的公司对测试人员是怎么看的呢?
我先说我们公司,项目组中测试人员有统一的专注测试的leader,他们只对测试Leader和自己负责的程序负责,不受开发组的任何“领导”指挥。在选人上,基本用两种人:1、“工作仔细”,这是女生的特性。2、思维严谨,有时候是技术也要比较好的。所以,没有人“瞧不起”测试工作和作测试的人。 |
|