大话人生

  IT博客 :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理 ::
  299 随笔 :: 0 文章 :: 73 评论 :: 0 Trackbacks
 

在陪伴公司与之共同成长的2年半的测试之路上,走到今天自身遇到了前所未有的测试发展的瓶颈。

 

公司的测试部门如何发展?

如何提高测试部门的工作效率来保证产品的质量?

测试部门是否需要发生重大的变革?

如何提高测试人员在公司中的地位?

个人如何继续软件测试?

个人如何去培养和提高测试团队的战斗力?

我们的软件测试和大公司的差距在哪里?有多大?

……

这一系列的问题一直在困扰着我,也一直指引着我去寻找它的答案。

 

以自己作为一名普通测试员在公司的所见、所闻、所感,以及在工作中所面临的问题,急待想解决的问题进行了描述;仅仅针对工作中发现的一些问题以及自己加入clochase测试部门2年半来所经历的测试之路发表一些个人的想法,也希望能够帮助公司和自己快速成长。

 

测试工作中的疑问

对于自己在测试工作中,一直有些疑问没有解开。主要有两点:

 

第一个问题,测试部门的定位

自测试团队成立至今,公司一直称为QAQuality Assurance),顾名思义:质量保证人员。一个对于整个软件项目活动中,对整个软件项目过程进行监控,以反馈给团队和客户质量的质控人员。而目前公司“QA”部门所做的是对已开发完毕的软件进行验证、测试以及反馈,发现足够多的问题和BUG从而来保证软件的质量,准确的说应该是软件测试人员。

 

我们如何来对自己的职位进行定位?是继续做一个合格的测试人员,作为软件工程中质量保证最后一道把关人,还是继续发展成为一个对软件工作流程进行质控,准确把握整个软件项目质量的QA?而我们如何在测试的基础上像QA的方向转型?或者说当公司有必要建立QA团队的时候,我们应该具备什么样的能力去与之匹配和胜任?

 

第二个问题,测试部门的发展方向
测试团队的发展是摆在目前团队面前很重要的一个问题,相信很多测试员工会有和我一样的疑问。测试部门的发展方向是否有考虑到发展测试团队成为一个有效的盈利团队,替用户设计解决方案,进行第三方测试,拓展新的业务领域?还是做一个自主研发产品,与软件开发紧密配合的协同人员?

 

如果说测试团队的发展方向是拓展新的业务领域,成为自主独立的团队。但是目前或者说接下来的几年里依靠什么样的的测试技术水平和素质才能实现此目标呢?

 

测试工作中面临的问题 

1)测试管理流程不规范

测试版本由于缺乏合理的配置管理流程而失去控制,测试计划很难制定,基本上是等待开发人员开发完一个功能,马上进入测试,再反复修改、测试……

 

如何制定好有效的测试计划,让测试人员和开发人员之间的合作形成一种顺畅而且方便的沟通方式呢?

 

2)测试用例的编写与管理以及执行力度不足

测试用例基本不够时间编写,或者在早期编写出基本的、粗糙的测试用例,后面基本上不会按这些用例来执行,因为程序的变更过于频繁,缺乏需求控制,另外,测试人员忙于应付开发人员提交的测试版本,不会有时间完善和修改测试用例,导致编写的测试用例成为一个形式意义上存在的工具。

 

因此,有时甚至完全抛弃测试用例的管理,不写测试用例。而实际上测试用例的编写还是有好处的,测试用例被称之为软件测试的“指南针”,是指导测试人员如何对软件进行有效测试的坐标,测试人员能通过编写测试用例熟悉系统的业务需求(虽然有时候很可能需求文档也是缺乏的!)。探索性测试的方法和敏捷测试的模式是这个阶段主要测试模式。

 

此时也效法教科书的做法,建立测试用例库,但是测试人员没有意识到如何充分利用好测试用例,没有充分理解测试用例的设计的重要性,停留在表面的测试用例书写上。如何让测试用例成为真实有效的一个测试工具成为困扰我的问题。

 

3)测试过后没有测试报告

在一轮测试过后没有给出具体的测试报告,只是简单的把bug记录在bug管理器上,然后机械化的发布release notes。对于每次测试的时长和效率相比上次的测试效率没有有效的分析,不便于测试流程过程中的优化和改进,只是为了测试而进行机械化的测试。

 

4)自动化测试的实施基本上不存在

公司基本上不引用自动化的相关测试,或者尝试自动化测试,但是没有收到很好的效果,资源缺乏,尤其是缺乏自动化测试的相关培训,除了一些对自动化测试感性趣的同事,其他测试人员要么对自动化测试不感冒,要么没有足够的脚本编写能力。另外,缺乏完善的项目管理、配置管理制度的配合,大家只能进行非常简单的自动化尝试,并且停留在小范围、个人的尝试。

 

在目前公司的测试工作当中,往往需要一人多职。在如此高强度工作任务之下,凭借纯粹的手工测试,可以说根本无法保证项目或者产品的质量。因此引入自动化测试的模式可能会成为一种比较好的测试方式。

 

5)测试团队内部缺乏有沟通

目前测试小组之间的沟通和交流及其少,都忙于自己的测试工作或者项目。大家有下意识的认为,每个小组间的项目不同,所设计的内容和范围不同,在一起能讨论什么?以前的小组会议基本等同于工作汇报,没有真正起到交流和知识共享的目的。大家都一味的低头拉车,没有抬头看路,这样对测试团队的发展是很不利的。

 

6)测试人员需要在技术方面进行提高

作为测试人员有时听到最多的话是,“你怎么搞的,这个问题都没有发现?”,“这个不是bug,我不认为需要修改”。出现这样的情况固然跟测试团队目前的技术能力有很大的关系,测试人员没有充分的了解整个项目构架,或者是开发中的某种技术。有时会把一些正常的现象当作bug处理,又或者是对于开发知识的缺乏,对有些可能潜在存在的问题却没有及时发现。所以有时测试人员在开发人员面前处于一种弱势,有点随开发人员的决定去走的情况。只有加强自身的专业技能,让开发人员认同测试人员的能力,才能更加有效的开展测试工作。

 

7)质量如何保证?测试不仅仅是测试人员的专利

质量如何保证可能不仅是我们所考虑的问题,也是国内外几十年来,软件行业所考虑的问题,但是我们应该如何去面对和提高软件的质量?仅仅靠测试人员吗?有些开发人员对自己写的代码都不能保证没问题就丢给测试人员开始找bug,这样的测试不具备太多价值,或者这些代码根本不具备可测性。

 

测试人员仅仅是质量保证的一部分,而并不是质量保证的全部,它是质量保证上重要的一环,但可能有时它并不是质量保证中关键的一环。质量保证的概念不应该只有出现在测试团队的脑子里,而应该出现在整个项目团队的脑海中,从需求的分析的测试,架构实际的分析和测试,以及编码的单元和白盒测试等,质量应该贯穿整个项目团队。并不是说目前的测试团队都具备了架构分析测试和单元、白盒测试的能力,而是让具备这方面能力的架构师或者开发人员能够共同评审这些框架、代码,从而保证前期工作的质量。当经过项目前期的审核真正移交至测试人员测试号过后,这样的软件可能才更具备质量保证。

测试如何结合工作实际情况进行测试实施改进

(1)      测试流程的改进以及执行力度的加强

 

测试流程按照我们现行的机制是:

需求分析、编写设计测试用例、执行用例、release notes的发布

 

改进测试流程:
需求分析、制定测试计划、编写设计测试用例、执行用例、发布测试日志和测试报告、分析测试日志和测试报告、release notes的发布

 

流程图对比:

现行测试流程

改进测试流程

无测试计划的制定,对于时间的周期以及人力资源的安排,测试方案,测试策略以及实施何种测试方式没有准确定位,以至于自己测试过后对于产品的质量没有准确的判断

有测试计划的制定,制定测试的测试策略,以及人力资源的安排,包括测试的类型以及何时测试活动终止(这一项需要和PM协商,例如测试用例的执行效率达到95%通过,进行测试活动的终止)以明确项目需要完成的测试目的

无测试日志和测试报告,仅有bug记录,每次回归测试过后,对于此次回归测试的效率相比上一次测试的效率没法准确分析和对比,无法预见何种情况造成bug的问题(如开发人员的选择技术不合理,或者粗心不负责任又或者)

对于每次的测试过后需要给出测试日志以及测试报告,并进行分析查找原因,是否有以前修复的问题重现,问题处在框架方面或者是开发人员的自身原因

 

对测试流程的改进是让测试人员具有主动发现问题的能力。对每次实施测试过后对测试效果的评估,从而去发现测试方式的优劣,测试策略的是否有效实施,又或者是评估自己是否需要对测试计划进行调整,以完善测试部门对开发与测试部门交互过程中的监控。

 

2)测试方式改进

目前的测试可以说没有太多技术含量可言,纯粹的手工黑盒测试。这样的手工测试或许对于老板说是比较放心的,看到员工实实在在的去点击或者查看软件。但是在每天高强度作业,有时测试很疲惫的时候,又或者更新很紧急的情况下,测试人员无法对于所有的流程进行完全的回归而遗漏掉一些常规需要测试的流程,心有余而力不足。

 

如何做到短时间内彻底回归测试而且保证回归的质量了?说到底,测试是门完完全全的技术活,而非真正微软公司夸张的请一些已婚主妇就能测试的体力活,我们需要引入自动化测试。如何进行自动化,怎么样进行自动化是放在我们身边的一道难题。我们需要足够的了解自动化测试概念,了解测试工具,制定测试框架,需要强大的技术储备和专业技能知识。

 

对于我们目前可能会比较难达到完全去自动化实施测试,但是如果想测试工作的有效实施、快捷反应,自动化测试是必须去走的路,我们无法逃避。

 

自动化测试的优点:能够快速回归并且效率很高,在脚本对整个项目覆盖率很高的情况下完全相当于增加了一名测试人员。缺点也很明显:如果项目的框架不稳定,需求变化太频繁的情况下不适合用自动化测试,脚本维护的成本会远远大于实际手工测试的成本,但是结合目前我们公司的实际情况,维护项目过多,而需求的变更并未影响主题架构变化的情况下,完全可以使用自动化测试工具测试。

 

除此之外很多自动化小工具的应用对于项目的局部测试很使用,并不需要多昂贵的资金和多专业的技能知识。可以引导员工从比较容易上手的自动化工具开始入手。比如firefox自带firebug调试测试工具,xenu的链接测试工具等等。

 

我们的目的应该是鼓励员工,引导加指导员工迈进自动化测试,对软件测试有更加深刻的理解。

 

3)测试团队引入需求配置和版本配置管理

项目中经常会碰到需求变更太快,以及需求来的频繁过多,测试人员怨声载道,导致测试人员无计划、无针对性的去组织测试,给人的感觉是计划永远赶不上变化。项目中的需求变化多、更新频繁是很正常的事情,正是由于市场的变化太快,所以需求也不得不随之变化。

 

如何对每天来的需求进行有效的配置和管理了?不是每天的等待PM分发需求,说做什么而做什么,测试人员应该有权利和有责任主动的去评估哪些需求是紧急的,哪些需求是可以缓和的。需要“量力”而行,保证质量。因此在测试队伍中,测试人员应该对每天来的需求进行归档编号,定义测试级别,以此制定测试计划。

 

版本的管理同样重要,例如一个项目中,在3天中获得3个不同模块的更新包ABC,更新至STAG环境,这些包并不需求马上更新至生产,需要通过市场部或者上层领导的认可才能进行发布,但是这时有可能市场反馈需要对B(此称为B1包)包里的某个界面不满意需要修改,当修改过后,更新至STAG,覆盖掉了原又的B1包,但是市场对更新过后的B2包依然不满意,甚至回滚至以前的B1包,但此时可能由于当初的更新覆盖,以及丢失了以前的那个B1包,此时测试人员手中和开发都没有此包,如果开发手中还有此包,或者你有幸没有删除以前的B1包,问题并不严重,但是如果没有任何B1包的存根,需要开发人员重新开发,这就是很严重的问题。

 

如果某段时间内像上述的情况反复发生,那么孤寂测试人员的头已经大了。因此作为发布更新包和release notes的关键人员,测试团队应该有效的对需要对发布的版本进行配置管理。

 

4)加强和调动员工自身素质培养

目前由于测试组的技术力量以及工作经验都处在一个学习和摸索阶段,测试组的综合实力较低,大多数的测试组员的技术知识比较薄弱,需要引导和加强他们在技术知识上的学习以及让他们更多的更加丰富的认识测试这个行业。

 

可以通过测试团队集体交流的方式来加强和调动员工素质的培养,比如通过定期的测试团队内部会议分享经验,或者在论坛上做一个每周一话题这样类似的专栏,来提高组员对测试话题的兴趣。鼓励大家勇于参与,给大家一个自由发展和言论的平台。

 

前面提到的优势也是目前测试部门的劣势,由于国内测试部门的起步不久,大家对测试的认识不足。以至于测试所具备什么样的能力,该像什么方向发展都存在疑问,如何找到正确的测试方向成为劣势转变成优势的关键。

 

公司目前20人左右的测试团队在小中型企业来说相对资源丰富了,但是测试人员的自身专业技能参差不齐,甚至具备的计算机知识很少,有的成员又或者没有具备一点开发知识,如何让测试团队由目前的中级阶段向上发展,成为了制约其成员发展的瓶颈。

 

posted on 2008-07-29 10:52 大话人生 阅读(1176) 评论(13)  编辑 收藏 引用 所属分类: 测试基础

评论

# re: (原创)在clochase公司之测试有感 2008-07-29 15:13 d
测试工作中的疑问

第一个问题,测试部门的定位

你说的对,就是软件测试人员。你看你的合同就知道了。中文的合同上面职位。
质量控制是公司要过CMM等认证才需要的。说的有点太绝对。不过就是这样。中国公司目前没有自发需要
QA这个需求


第二个问题,测试部门的发展方向

公司的发展方向是赚钱。赚中国人的钱
开发部门能够创造直接的收益。他们做出产品,测试只是确保,严格意义没创造价值
至于谈独立团队。非常不现实。除非是纯粹的软件外包公司。测试才能创造属于自己的独特价值,不然永远

是开发的附属品
目前我觉得测试团队会一直附属。看招聘的人员层次和要求就知道了。



测试工作中面临的问题
(1)测试管理流程不规范

这个目前不无法改变。国内只有华为等通过CMM5的公司能够这样执行计划。
说实在的。让你和开发人员沟通。你能沟通出什么呢?
我觉得最现实的是。能够更深入的了解产品的代码。提早的构想出将要怎么测试,然后让开发人员在开发过

程中提供便利。这样在产品功能开发出来后。能够很快的很容易的测试完毕

比如一个功能需要每天晚上12点发奖。。你可以提早让开发人员吧这个时间点设置成可以配置的。这样在上

班时间可以测试了。

再比如QTP不识别那种控件,可以提前给开发人员说不要用那个控件。。。等等。


(2)测试用例的编写与管理以及执行力度不足

测试用例的编写。我觉得不是单纯的写文档。是要用到实处。特别是团队合作的时候大家能够通过彼此的用

例知道对方准备怎么测试。。可是现今浮躁的评比制度往往希望测试用例写的够多。篇幅够长。。等。这样

就失去了指导的作用了。

个人觉得测试用例一定要反映出测试人员的准备怎么测试。而不是简单的为了应付的罗列
不过这样一些不懂测试的领导又会说你们偷懒了,,
具体怎么,我觉得真没必要在这个问题上面太多的困扰。
测试用例其实就是一个让别人知道自己准备怎么测试的指示灯。。就这么简单。
项目合作的过程中。大家互相走查彼此的测试用例。看看对方有什么没考虑到。或者什么考虑的不周到。。
测试用例个人建议不要带数据。。纯指导。这样才有真实的意义。更没有必要按照测试用例一个数据一个数

据的来。。在软件测试外包企业会要求这样,一个用例一个用例的走。。不过别人也没有放数据

(3)测试过后没有测试报告

为什么不能够从bug管理工具导出来的。。。导出来的难道不是测试报告吗?不能给你一个标准衡量下吗?


(4)自动化测试的实施基本上不存在

你的想法非常不对。引进自动化测试需要很多前提条件。自动化测试绝对不会节约时间。
自动化测试只适合非常稳定的产品。

培训可以内部培训。今天你讲QTP。明天他讲LR。。这样也节约成本啊。

想开展自动化测试。最起码一半人要熟练的用。目前公司的那些女孩子。培训出来的。实在难当重任。何必

搬石头砸自己的脚。

我觉得实在想做。抽取一个项目。调几个比较熟悉自动化测试工具的人。一起试试。看能否开展。如果试点

成功。这些人组成一个组:自动化测试组。。以后这帮人做自动化测试。其他人继续手工。。目前大部分公

司是这样的


(5)测试团队内部缺乏有沟通


需要交流什么呢?你觉得会议需要谈什么。你可以提出来。这个无所谓为了开会而开会,比如你希望让大家

聊技术。就工作汇报后谈下技术。一期找个主题。和以前的英文topic一样


(6)测试人员需要在技术方面进行提高

技术方面=编程,看代码
其他的一切都不重要。什么linux。数据库啊。。那些都是辅助的技术方面,不会编程一切等于白搭


(7)质量如何保证?测试不仅仅是测试人员的专利


下面的不写了。。哈。因为觉得你这样写没有半点用。不用浪费时间了、







  回复  更多评论
  

# re: (原创)在clochase公司之测试有感 2008-07-29 16:37 大话人生
@d
呵呵,很感谢公司的这位同志拍板砖
也谢谢对我所提的问题的点评

1.第一个问题,测试部门的定位
质量控制是公司要过CMM等认证才需要的。说的有点太绝对。

难道质量控制只需要在过了CMM吗?仁兄是有点说的绝对了,CMM等只是一个帮助改进工作流程保证工作质量的的一个模型而已,难道要真有了CMM才有质量保证吗?犹如CET-4考试,难道过了CET-4就是具有了英语的四级水平了?

对于公司的QA,貌似这个问题其实很早就意识到了,公司测试人员的职责就是测试,所以我的目的就是要去掉扣在脑袋上面的那个头衔,那个自始自终都要保证质量安全的QA头衔。但是话也说回来,如果公司对软件质量的重视继续加强,如果需要对工作流程进行监控和优化,那么QA是有必要出现的。这是后话了,呵呵~~

第二个问题,测试部门的发展方向
他们做出产品,测试只是确保,严格意义没创造价值
至于谈独立团队。非常不现实。除非是纯粹的软件外包公司。测试才能创造属于自己的独特价值,不然永远是开发的附属品目前我觉得测试团队会一直附属。

这点,我很不认同仁兄。测试没创造价值,需要测试干嘛,养帮测试干嘛。测试和开发的价值刚好体现在两个有形和无形价值两个方面。测试团队的独立体现在多方面,可以是工作方式的独立也可以是创造价值方面的独立,就像你说的,去承接外包测试,那样的有实物的价值可能更加让人认可而已。

(1)测试管理流程不规范
说的不错,基本同意你的观点,这也是需要在整个项目计划以及开发计划和测试计划中来实施和调整的,改变这种测试完全跟着开发进度跑的局面。

但是不认同你的‘让你和开发人员沟通。你能沟通出什么呢?’
测试为什么不能和开发沟通,而且沟通是必不可少的。
首先进行完一轮测试,我们首先来定位这些问题主要集中在哪些方面,是由什么情况导致的?是否有开发的态度问题(例如自己不先测试过,或者对自己开发的代码都没有信心就抛出测试)。是否有业务理解方面的差异,又或者是框架本来设计就有问题,测试在开发的过程中能够提供一些必要的数据以帮助开发人员能够更加快捷的进行开发设计。

(2)测试用例的编写与管理以及执行力度不足

很同意你的观点,用例没必要一开始就代入数据,那样在需求变更的情况下,维护的成本更大,而应更多的考虑他的实效性,以及通用性,大家都能够使用同一套用例进行同样的测试,这个用例境界还是比较高的,但是会像这方面努力

(3)测试过后没有测试报告
为什么不能够从bug管理工具导出来的。。。导出来的难道不是测试报告吗?不能给你一个标准衡量下吗?

仁兄可能不在公司很久了吧,还是没用过公司的这些bug工具,目前的这些bug工具如mantis之流还不具备测试报告的发布以及分析功能,这也是为什么我提出要走自动化道路的原因,所谓自动化就是融入人的思想,让计算机替俺们办事

(4)自动化测试的实施基本上不存在
你的想法非常不对。引进自动化测试需要很多前提条件。自动化测试绝对不会节约时间。
自动化测试只适合非常稳定的产品。
培训可以内部培训。今天你讲QTP。明天他讲LR。。这样也节约成本啊。
想开展自动化测试。

你可能还不了解自动化测试的真正含义吧,不是所有测试都需要版本稳定了才去做的,自己编写一些小工具为什么就不能做自动化测试了,难道一定需要在系统测试的时候,版本稳定的时候进行自动化测试吗?你指的可能是QTP和LR这些大型工具,按你的培训思路,这样是需要技术力量支撑的,在自己都没有完全掌握这些工具的时候如何去给人家培训?这个成本貌似也很大啊。

(5)测试团队内部缺乏有沟通

沟通是必然的,没必要一定去开个会,但是开会是最容易拉近大家距离的方式,而且看下公司的各位一个闷声发大财的,也不会搞个topic就来和你跟帖吧。

(6)测试人员需要在技术方面进行提高
技术方面=编程,看代码
其他的一切都不重要。什么linux。数据库啊。。那些都是辅助的技术方面,不会编程一切等于白搭

恩,这个讲的很实在,目前测试部门就是欠缺这方面的技术才能,也是我提出来的疑问,其实更加需要开发背景的人员加入

(7)质量如何保证?测试不仅仅是测试人员的专利
下面的不写了。。哈。因为觉得你这样写没有半点用。不用浪费时间了、

但是也很感谢你对我的观点和疑问拍砖,希望继续拍砖,帮助提高,谢谢了:)  回复  更多评论
  

# re: (原创)在clochase公司之测试有感 2008-07-29 18:29 d
看了你的回复。主要以下分歧
1:如果需要对工作流程进行监控和优化,那么QA是有必要出现的。项目经理就是干这个的。老板也是干这个的。并且谈优化监控。职位一定很高。水准一定相对牛。让这样的人做QA。公司请的起吗?愿意花这个钱请吗?

QA存在一定有他的价值。只是暂时不适合现在公司

2:测试的价值问题
这样说吧。如果一个产品10分的价值。开发7分,测试3分。至少目前的公司是这样。我这样折你不会不同意吧。如果这样按照价值折合工资。是不是老板会给开发7000,只给测试3000呢。或者给你6:4,开放6000工资。测试4000工资。这个就是现状。不仅公司是这样。整个中国软件业都是这样

和开发并行的测试。创造了价值,不过不够多的价值
只有独立。才有10分的价值,这样才能牛

3:让你和开发人员沟通。你能沟通出什么呢?’
你误会我的意思了。你总结的对

4:自己编写一些小工具为什么就不能做自动化测试了
这个我能够理解为简单的自动化测试吗?或者自己写你不觉得成本更贵。
如果公司推行的是你这种简单的自动化测试。就不是真正意义的自动化测试

QTP,LR是企业级自动化测试工具。想想培训成本当然高。不过想自动化测试这是必经之路。当今社会还没有任何一个自动化测试工具有上面两个强大好用(IBM的那个易用性非常差)。不然你blog也不会学这两个了

一定要很会才能教人吗?让当leader的时候。你已经能够带领团队了吗?
相互学习是个过程。大家一起讨论。这样就能进步。

5:
  回复  更多评论
  

# re: (原创)在clochase公司之测试有感 2008-07-30 01:14 大话人生
@d
呵呵,这么晚了,上来看看,又看到仁兄的发言了。可能我们还是有些观点不一致。

1:如果需要对工作流程进行监控和优化,那么QA是有必要出现的。项目经理就是干这个的。老板也是干这个的。并且谈优化监控。职位一定很高。水准一定相对牛。让这样的人做QA。公司请的起吗?愿意花这个钱请吗?

目前BOSS,项目经理可能都把经历放在这方面,但是他们长期以往的主要职责和工作重心是这个吗?又或者说质量监控只是一时的不需要长期进行下去的工作吗?如果工作重心是这个的话,未免这些牛人也太贵了。QA只是一个职位,并不代表他的能力和地位高低。
请逆向思维考虑下,为什么不可以安置QA做质量监控,然后配合项目经理,又或者以后的技术监督部门来一起监控和反馈质量信息了?为什么不把一些愿意做相关工作的测试人员或者同事安排来做QA了,QA难道就不可以上升为以后的项目经理了吗?为什么公司一直要求测试人员再三的说保证质量,保证质量,但是确没有给予测试人员保证质量的机会了?质量监控是一个长期的工作,而不是一时的热血沸腾的想法。

2:测试的价值问题
这样说吧。如果一个产品10分的价值。开发7分,测试3分。至少目前的公司是这样。我这样折你不会不同意吧。如果这样按照价值折合工资。是不是老板会给开发7000,只给测试3000呢。或者给你6:4,开放6000工资。测试4000工资。这个就是现状。和开发并行的测试。创造了价值,不过不够多的价值
只有独立。才有10分的价值,这样才能牛

我看关于测试的价值问题,我们不用这么深究,对于国内的现状是,测试行业很火,但是重视程度不高。门槛低,被认为是没有多少开发能力或者能力不行的人所从事的职业。
对于你说的价值,我不明白你的绝对价值是什么?如果说一个发布的产品,我们怎么看待他的是价值了?我们不拿阿波罗号事件啊,掉颗螺丝啊就一切88的的科研东西来打比。如果说一个产品,没有经过测试人员的严格测试和最终的评定审核。他发布出去的风险有多大?从我的朋友那里一些公司是没有测试人员的,发布出去的东西没有严格测试,漏洞百出,问题多多(并不是人家开发不牛X,我想再牛的开发在压力中也难免会犯一些错误吧)。最后就是人家不买你的单,说你做的东西操作性不强,使用不方便。问题还超级多,当你拿着这样的东西让人买单的时候,价值几乎要接近0了,呵呵~~~但是话又说回来如果一个成功的,质量有保证的产品一经发出,那么开发和测试的价值比是多少,谁去衡量了?可能一个当时让你的产品变成0的BUG被测试发现了,挽救了你价值为0的产品怎么去评估?是10还是0,又或者是7还是3?你能告诉我吗?测试人员能力有高低,只是目前我们公司的测试人员能力还不足(这一直是困扰我的一个大问题),所以说请尊重测试人员的价值?所以说做测试难,做成功的测试人员更难。
如果说测试人员外包项目去创造的米米,那个似乎不叫价值了,那叫公司的外快或者说是给自己公司创造的利润给被外包公司创造的价值了。哈哈~~~~~~~~

4:自己编写一些小工具为什么就不能做自动化测试了
这个我能够理解为简单的自动化测试吗?或者自己写你不觉得成本更贵。
如果公司推行的是你这种简单的自动化测试。就不是真正意义的自动化测试

什么是真正的自动化测试?世界有没有真正的自动化测试?看来你这个要去GOOGLE或者BAIDU下了,世界上目前上还没有完全意义上的自动化测试。按公司的大小和成本的收益比,当你的花费的构建自动化框架能节省你的成本就是自动化了。
例如:我们公司经常要认为的对比文字的正确与否,我们为什么不写一个方便益用的核对工具,让人能够很容易和准确的去识别这些差别,而不用去一个一个文字的核对了?(目前的ULTRAEDIT工具的核对功能并不好使)这个工具不是一时所需可能是以后的项目中经常要使用的,你说这个是不是自动化测试?(可以看我写的其他BLOG)
另例如:如果我要测试一个用户登录网站退出网站100次或者更多来验证,登录中是否有bug又或者其他的流程操作N次,(这个问题曾经在BELL项目中已有应用)这时,使用自动化工具来测试这算不算自动化了?
再比如:我们每次提交BUG要开发人员去看BUG,然后开发人员改了个BUG就提醒测试人员去验证,依次反复,是不是浪费时间了?我们为什么不对BUG管理器进行邮件提示,当改完一个BUG或者提交一个BUG会自动邮件给相关人员了?
所谓的自动化不是说开个机器在那里,程序就一直跑,跑出BUG来的自动化测试是不符合现实社会的,这种自动化只能是美丽的泡沫。我所说的自动化就是让机器代替人为的体力活去做一些重复的工作。
再说了多完美的自动化测试也是从小的自动化测试开始的,只有让人尝到甜头,大家才会去向这个方向发展和拓进。我的想法是小范围小甜头到大范围大成果。

现在的LR,QTP工具确实是最流行的工具,只能说流行,并没有你想像的那么强大。IBM的那一套工具益用性相对是较差,但是非常的强大和体系,只是一般公司更用不了,也不理解IBM的工作模式和工作理念。任何的测试工具都有自身局限性,在我用过的QTP和LR进行项目测试都有自己的局限性,不是说任何项目都可以使用HP的或者MECURY的万能工具解决的。都需要自己来改写脚本,进行脚本的开发和维护来完成项目的自动化测试的。而且并不是完全的自动化。
可以再打个比方,MS是从来都不用上面的那些他们认为不入流的工具的,MS的话,呵呵。他们有自己的一套自动化工具开发,而且这些工具并不是万能的,都是根据现有项目的实际情况和成本核算来开发的。

沟通使用工具不是说不可以,而不能说培训,因为目前公司自身能熟练掌握这些工具的人几乎没有。而且未必人家对这个东西感兴趣,如果说讨论也是针对感兴趣的人而言的。所以这是我提出的为什么要引入自动化测试,要引导,要渐进。而不是强制大家用, 一定要让大家尝到甜头,才能更多的开展工作。  回复  更多评论
  

# re: (原创)在clochase公司之测试有感 2008-07-30 01:18 大话人生
哈哈,说了这个多,其实我提出的很多问题,有些是心里有点底的,也是事实在在存在的问题。这个东西也发公司的论坛了,我的目的只是希望上面给予更多的关注和支持,如果没有支持,我想我再有更多的想法或者建议都没法去实现和实施。哈哈,目前也只能作为一种建议和反馈

不过还是很感谢大哥的支持。公司论坛一片叫好之声没有太多意义。这样的拍砖才实在。
以后多来踩踩,多拍拍砖,有些建议还是很可取的。^O^  回复  更多评论
  

# re: (原创)在clochase公司之测试有感 2008-07-30 12:34 d
看得出你很有思想。非常有见解。不过你说的他太理解,太不现实,又或者我太现实

为什么说不现实。
公司的重视度不够。。这个是最要命的最关键的。不解决这个问题其他都是空中楼阁

公司不重视,给测试人员的权力不会很大。测试要做开发的奶妈,

公司不重视,给测试人员的工资比开发低,别告诉我谁伟大到吧钱不当回事,这个为什么开发的比测试的工资高,最下面有论述

公司不重视,给测试人员的定位会局限,“测试就是点点,有多难”,这样会做出一些很不尊重测试的事情。比如一个项目一天测试完(很短时间),这种不经过大脑的话。

公司不重视,给测试人员的人员来源不重视,节约成本首先想到砍测试的成本,请一些培训的。女的。。不是说这些人不好。也不是歧视女性,不过很现实的是砍他们这些人的工资比砍一个大学毕业的男学生的容易。这些人组成的测试团队。水准一定开展不了自动化测试(有点过于绝对,不过也差不多了,)

我一直强调开发是根本。测试是增值。你不承认也不行。
首先极端的没有测试人员。这个在测试行业出现前一直存在。没见他们卖不出去。他们不是不测试。是他们开发人员兼职测试了。可是这个开发人员的主要任务核心任务还是开发。测试在这个时代只是补充。就是我说的增值,
现在出现了测试人员这种职业,测试的价值只是更加增值点。不过也不是核心

说多了没有意思了。等你工作4年后就知道了。
开发4年拿个年薪10万很多。测试的就难了。。这个就是最好的佐证。开发是根本价值。测试只是增值服务

不过说这些不是说测试不行。测试不好。只是说中国的测试行业就这样。不要自己骗自己。多要想开发方面转。多要学会编码能力。一个有编码能力的测试人员除了测试的增值服务外。还有开发的一些基本价值,这样加起来才能够转变为高薪,

我说的上面是从纯技术层面说


当然如果想走管理路线。上面的纯属放屁。。管理就是混。混到项目经理能不高吗?至于要达到项目经理是什么样的测试人员。已经有很好的例子。我们都需要好好崇拜和体会


  回复  更多评论
  

# re: (原创)在clochase公司之测试有感 2008-07-30 13:44 大话人生
@d
恩,哈哈,看来我们平时私下里很少交流,这里却成为了我们讨论的一块小区域。

你说的那些道理我都能理解。我并非一个理想主义者,而是一个现实的人。说白了,我进公司前是想做开发的,但是出于当时公司的考虑,不能说我有多么伟大,我确实牺牲了点自己的利益,做起了测试工作,一做就到现在。从当时的对测试的不理解到现在的推崇。

不是说测试职业有多么伟大,而是既存在即合理。现在软件行业的发展壮大已经细化到很小的部门和职业。可以说测试这个东西自从有了计算机开始就拥有了测试,只是前10几年把他作为了一门独立的学科来分类(我指国外)。

公司成立测试部门的初衷也是希望测试人员替开发人员减压,使开发人员能够把更多的精力投入到产品的研发过程中,也从而更高标准的产出我们的软件。从当时clochase的精英团队(我当时的认为)到现在的水平参差不齐,没有门槛,白菜萝卜一起抓的现状。我真的有点失望,不是说公司不能够容纳有水平高低不同的人,公司是要具有形形色色的同志。但是目前的现状和人员梯次根本就是毫无界定。没有一个团队的梯队模式,没标准,想要人了,不问情况往里招,不好了有的能力不怎么样的还不忍心裁掉。这些招进来的人又能创造多少价值了,有的可能反而成为了一种负担。我在这也不是指责我们的上层,而是希望能够有个评判的标准,一个入门的门槛。

你说的开发是根本,我基本同意,而我的理解是计算机技术能力的支撑应该才是根本。软件行业毕竟是门技术活,无论开发,测试,IT支撑或者网络管理等等的IT人员啊没有技术的支撑想在技术的行当里混下去,或者说没有扎实的技术想有质的提高是不现实的。

我目前承认测试在公司是增值,但是我的目的就是,竟然入了这一行,为什么不把他做好,为什么不能直接去创造利润?为什么一定要去成为一个附属品了?公司竟然成立了测试部门为什么就不能够把测试部门做的更好去创造更多的价值?我想当初公司成立测试部门的初衷也不是基于国内测试行业兴起的跟风。而且测试行业的外包增值在市场上还是有利润的。我们为什么不能抓住这个切入点让公司去支撑下了?我并不是说我能力有多大,而是希望带着可能自认为的一些理想在这里想和公司赢得共赢的机会。所以路还很远,但是我一直在像这方面有努力,成效永远胜于口水仗。

对于你说的公司的女测试人员又或者是才培训出来的人员,我跟你有同样的感觉。有些同志连基本的SQL语句都不会写,又或者根本就不了解一些开发的基础知识,不了解什么进程,什么线程。什么是session什么是cookie之类的基础知识你说如何去做好测试?不对测试的项目进行深入的理解,不了解大致实现的机制和框架,如何更深入的去展开测试?我在这并不是说一些女同志,而是一些同志,有些女同志还是不错的。
貌似我们公司的测试人员连基本的开发能力都不要求就抓进来了。连随便用种语言写出1+2+······+100都写不出来。在这种情况下我们公司想实施自动化测试就是天方夜谭。自动化测试的前提就是要具备扎实的开发功底。这也是实现测试人员自我价值提升和涨米米关键点,我曾经也美好的设想过公司为什么不可以分成STE和STDE?一个美好的梦。

说是几点,说这么多,做这么多无非希望得到公司的关注,关注测试,关注测试的发展,也如你说的提升我们的米米,但是如何提升,我不可能每天指望老板和上层来发现,而是希望通过成效和实际行动来自我增值。但是我现在缺少的就是和其他测试人员的沟通(内在的一些原因,大家都很清楚,呵呵~~~),还有就是缺少上层给予的支持。如果有了这两点,我相信做起来会比现在轻松许多。

你是一个工作了多年的好leader,哈哈,很感谢你对我的回答,能够这么热诚和诚心的告诫和提点。希望能够以后更多的探讨。  回复  更多评论
  

# re: (原创)在clochase公司之测试有感 2008-08-04 14:47 MM
对于你说的公司的女测试人员又或者是才培训出来的人员,我跟你有同样的感觉。有些同志连基本的SQL语句都不会写,又或者根本就不了解一些开发的基础知识,不了解什么进程,什么线程。什么是session什么是cookie之类的基础知识你说如何去做好测试?不对测试的项目进行深入的理解,不了解大致实现的机制和框架,如何更深入的去展开测试?我在这并不是说一些女同志,而是一些同志,有些女同志还是不错的。
貌似我们公司的测试人员连基本的开发能力都不要求就抓进来了。连随便用种语言写出1+2+······+100都写不出来。在这种情况下我们公司想实施自动化测试就是天方夜谭。自动化测试的前提就是要具备扎实的开发功底。这也是实现测试人员自我价值提升和涨米米关键点,我曾经也美好的设想过公司为什么不可以分成STE和STDE?一个美好的梦

你说的有些对,但是绝大部分很抨击公司的女孩子。我觉得测试人员有开发基础当然是好的,至少对于现行的商业化测试来说有开发功底,一定是好的。但是你有没有想过其实公司很多测试页面都是开发人员开发的,而且都是在实际中应用,而且也应用的很好,而且女同志也测试出了一定的bug,难道你说她就一点不懂吗?做不好测试吗?

自动化测试,你的观点我很认同,确实可以从小自动化测试开始。但是对于公司现行项目使用企业版的测试工具合适吗?需求变更如此迅速,而且还是两三个月就要提交上产品,对于这样的项目我想自动化测试根本是不现实的。
我觉得测试应该是从需求开始,我觉得现在大多数测试人员根本不懂需求,何来测试设计,测试用例。基本上就是看着别人怎么操作,就跟着操作,对于你说的


现行的中国测试局面就是这样,找个合格的测试人员本来就难,何况公司的人员招聘是与北大青鸟搭线。你想想北大青鸟去就读的又是什么人?

其实你的观点我很认同,对于公司现行是需要人提出来的。初次进入公司的感觉就是觉得测试混乱,什么测试规范,测试用例,我觉得连基本的缺陷管理都用得很少,基本邮件发送,感觉没有一定流程管理,今天发现的bug,过了明天都没有人去打理,可能是不同的组原因,也可能是一开始就这样。没有具体的项目介绍,没有框架介绍,没有培训,至少我觉得他们更是一个技术人员,对领导的管理根本不懂,所有团队成长更是难上加难,公司发展就更难上加难了。
作为一个领导或者组长然后测试,请问这样的测试结果准确吗?我觉得了解需求是基本,但是公司测试人员根本没有意识到。
而至于沟通,我觉得真的开会根本没有人提出,也许是人在其位谋其职了,毕竟还是有很多顾虑,要不也不能采取这样的方式来讨论。
测试人员学习质量保证,一定好好处,但是那是质量保证工作人员做的,作为测试人员又何必太追究什么CMM,ISO什么了。毕竟测试只是质量保证的一部分。学会测试技术才是硬道理。
  回复  更多评论
  

# re: (原创)在clochase公司之测试有感 2008-08-04 17:59 大话人生
@MM
你说的有些对,但是绝大部分很抨击公司的女孩子。
楼上的美女,不好意思,我不是有意针对女孩子,可能是女孩子比较多让你产生了这样的看法。我没有歧视公司女同志的看法,女孩子在目前的测试行业中的优点是细心,耐心,很有责任感这是女孩子的优势,他们能够发现软件中的很多问题。但是有些人满足于现状,没有对自身技术上以及知识上更严格的要求,觉得自己不错了,一直停留在刚开始的阶段,没有想办法去提高自己。我在这不是说他们做不好测试,而是如何去做好测试。只有更高的去要求自己觉,提高自己的能力才能更加深入的去开展测试,也才能够让测试人员扬眉吐气。如果真有伤及到你了的话,我道歉。


自动化测试,你的观点我很认同,确实可以从小自动化测试开始。但是对于公司现行项目使用企业版的测试工具合适吗?需求变更如此迅速,而且还是两三个月就要提交上产品,对于这样的项目我想自动化测试根本是不现实的。

公司目前的项目有很多适合,为什么?因为目前公司的很多项目处于后期的维护阶段,并没有对流程进行大的改进,伤筋动骨。但是每次更新一个小的需求,大家都要完整的走一次流程,还要担心有的功能是否有测试到,连自己都没底,不是吗?我们为什么这个时候不借用自动化测试工具了?
还有自动化测试工具不是说一定要版本稳定了,只要你所使用的工具能满足你的测试需求,减轻你的工作量就已经达到了自动化测试,比如一个网站的所有链接要你去测试你怎么测试?一个一个点还是使用网页链接测试工具Xenu了?

我觉得测试应该是从需求开始,我觉得现在大多数测试人员根本不懂需求,何来测试设计,测试用例。

需求开始没错,话又说回来,如果在需求阶段,你是否需要考虑开发采取的何种开发模式或者框架技术,设计到了哪些方面是需要侧重测试的如何测试的了?你要知道客户有时给你的根本不是一个完整的文档,而是需要技术人员去按照用户的需求整理成我们想要的需求规格说明书等,实际意义上我们现在项目拿到的不是用户真正意义上的需求而是由JBH等同事整理的需求规格说明书。所以更加认真的读懂和理解需求是需要阅历加上技术来支撑的。像你说的那样的测试人员,建议让公司裁掉,呵呵~~~


现行的中国测试局面就是这样,找个合格的测试人员本来就难,何况公司的人员招聘是与北大青鸟搭线。你想想北大青鸟去就读的又是什么人?

这个你可能要挨批了,进北大青鸟的也有名牌学校的同学,只适合在大学里可能学到的东西觉得在社会上不至于立足才去继续深造的。


呵呵~~~~~~看你上面说了那么多,我们公司的问题大家都看到了,问题是如何来解决,怎么来解决的问题?难道上面不关注了,我们也不学习了吗?总之,现在为了公司测试的明天也是你我测试的明天。大家一起努力吧  回复  更多评论
  

# re: (原创)在clochase公司之测试有感 2008-08-06 12:56 d
本来谈的是公司的测试的发展。没想半途得罪了这些女测试人员又或者是才培训出来的人员。

这里不说你们好坏,也不评论你们的重要性,这里我列4个标准。你们自己衡量下:
1:有认真看需求文档,并且全部搞清楚每个细节吗?如果拿到一个需求文档没有很多问题。测试的时候一定不全面。(英文不好的话,有想过全部汉化吗?对需求不明白的地方除了和开发的沟通外,有想过和JBH沟通吗?)

2:写过测试用例吗?并且在项目中一直执行的(3个月的时间够你写的,需求的更新你可以自己更新测试用例,不要说公司不给你环境,这是便于自己测试的事情。测试用例的作用就是理顺自己测试的头绪,让自己不是盲目测试)

3:有用过任何小工具小软件做过测试吗?比如大话人生说的Xenu?(用这些学这些不需要几天的时间,所以每天很劳累的点链接。对文字的时候有想过去收集些工具提高效率)

4:每天劳累的测试工作后,有想过怎么去提高效率吗?(工作的流程很难改变,所以大家寄希望于自动化测试,你们想过吗?有去尝试吗?)


如果你想过并且做过上面四个问题的3个以上的。我们向你道歉
如果没有,希望你自己调整下心态。因为想成为一个好的测试人员。
想多拿米米。这些是最基本的。

一个没有任何思想的。整天说自己累的测试人员。是被想指望公司给你多好的地位,多大的待遇。

多思考,多积累。多听取下别人的意见。多上网上论坛看新鲜的测试大小事。
测试的发展就两条路:
1:管理===(公司熬个几年应该是leader,再熬个几年经理)
2:高级测试工程师==自动化测试或者性能测试(绝对了点。不过差不多了)

所以走技术路线,或者想提高自己的技术。自动化测试是无法避免的。
早点正视这个问题。早点准备不是更好吗?
  回复  更多评论
  

# re: (原创)在clochase公司之测试有感 2008-08-07 10:38 MM
楼上的不知道是那位公司的管理人员,会因为我对公司的测试现状看法来如此衡量我是没有达到这四个标准的人。而且我觉得这四条标准也不是衡量一个测试人员的真正标准。如果现在进来公司的测试人员有没有到达你所说的那个标准进来的测试人人员,不是合格的测试人员,哪么公司为什么要请这样人?
我觉得测试范围在于广而在于精,而公司做web测试也只是测试领域的一小部分
其实测试发展不仅仅在乎公司某些测试人员怎么高深,更在于团队力量的成长,所以说测试管理水平上也是要一定的提高,真所谓测试环境 也会造就一部分好的测试人员出来。
感觉这位管理人员是从开发人员转为管理人员,而没有真正经历过测试,何谈好的测试管理?我曾经看过一本书《核心测试过程:计划、准备、执行和完善》。这本书就把测试人员合理分配为手工测试人员,自动化测试人员,测试环境管理人员三个方向来建立一个优秀的测试团队发展方向。为什么我们公司不能这样做了,让不同的人擅长不同的测试领域,就跟开发一样,有人。java好,有些。net好,也有些vb好。我觉得管理人员就是要学会发挥自己员工的长处来利于公司发展。
我不否认自动化测试或性能测试是以后的发展方向,但是这些东西又何来一个人可以搞出来,总的来说还是要靠团队,就像一个再牛的测试人员,他也可能一个人编写一个操作系统来一样。我想楼主谈的这边文章也不是针对单个的测试人员来说的,而是公司整个测试团队的发展。
所以我也希望公司整个测试团队能快速发展,而不是针对某个测试人员。  回复  更多评论
  

# re: (原创)在clochase公司之测试有感 2008-08-07 13:32 d
如果现在进来公司的测试人员有没有到达你所说的那个标准进来的测试人人员,不是合格的测试人员,哪么公司为什么要请这样人?

因为节约成本?这么简单的问题。自己体会吧

我觉得测试范围在于广而在于精

不知道你是说要广不要精,还是都要。“全才”没有专才发展。这个是大趋势。


为什么我们公司不能这样做了,让不同的人擅长不同的测试领域,

节约成本,。。。节约成本。。。(这个MM估计刚毕业,或者太理想化,有机会和你的老大或者工作多年的人沟通下。)

总的来说还是要靠团队,就像一个再牛的测试人员,他也可能一个人编写一个操作系统来一样。

这个是个大话题。我们只是细化到小的细节。
一个公司的自动化尝试,。一定是一个人或者一个小组。。没人吃螃蟹。能够成功吗?先少数人富裕,然后带动大家共同富裕。
所以需要请或者内部培养一两个“牛人”试点实行。

所以第一步是要有这样的牛人,接下来才是推广,也就是你说的团队共同发展。你难到天真的指望公司会让你们一起尝试自动化。那样风险太大了。

但是目前进来的项目繁多。进来的人员水准不够。实在难以找这样的牛人出来。即使尝试成功了。这些人数能够跟上共同富裕的脚步吗?说到这里有些杞人忧天了。

我上面的4个标准其实就是说测试人员要
1:细心对待工作
2:有规划,有条理的测试
3:主动去学新鲜知识去克服工作中遇到的问题
4:思考。反思。总结


这几个是最基本的。做事情的态度,没有涉及到任何技术层次的。更谈不撒谎那个衡量一个测试人员,如果这些都做不到,真的是为你担心了。如果公司一直招都达不到这些最基本标准的人。后果可想而知。。。。那就继续慢慢的手点吧。

放心吧。熬个2年运气好一年。你就是leader了。技术不技术。无所谓了。再熬个几年,运气好就是项目。。。不过女孩子做项目经理比较难。你要加油。

我一再强调的是从技术角度谈发展。不是从管理角度谈。

所以稍微偏激了点。不过咖啡就是苦的,加再多糖一样是苦的。糖再多了就是糖水不是咖啡了。所以测试的现状是什么样就是什么样,改变是从咖啡自身改变。不是指望糖


  回复  更多评论
  

# re: (原创)在clochase公司之测试有感 2009-04-11 14:27 风中雨
压根就一垃圾  回复  更多评论
  

只有注册用户登录后才能发表评论。