软件测试工程师工作定位之我见

上一篇 / 下一篇  2013-01-31 10:36:01 / 个人分类:杂谈

好久没有写blog了,主要两个原因,一是因为新换了工作,事情比较多,抽不出时间来写。二是对自己的工作定位有些迷茫,一时搞不清楚软件测试工作的定位,所以不知该写些什么。不经意间我工作也快五年了,除了刚开始编写了一年左右的代码外,其他时间一直在做软件测试工作,而且一直想做一个非常专业的软件测试工程师。但最近几个月却感到有些迷茫,找不到软件测试在整个软件过程中的定位,思考了很长时间,最近才有了一点心得,趁十一长假的时间拿出来与大家分享一下。这只是我个人的一点看法,还不成熟,有不对的地方还望大家多多包涵!

  刚开始做测试的时候,并没有经过什么系统的学习和培训,也没有其它前辈的制导,只是从网上或者书上看了一些测试的理论就开始了尝试。刚开始的一年里,根本没有想过测试工作的定位问题,只是把自己当成了一个骨灰级的普通用户,每天就是翻来覆去的尝试着待测试程序的各种功能,想方设法的找出程序中的各种错误。发现错误后先暗自得意一番,然后提交给开发人员。随着程序实现的功能越来越多,工作也越来越累,不但新开发的程序会有错误,以前修改过的错误也重现了出来,整天搞的焦头烂额,不胜其烦。好不容易把所有已发现的问题都修复了,程序开发也进入了尾声,麻烦也随之而来。程序是做个用户使用的,是由公司的市场和技术实施人员帮助客户使用的。但市场或技术实施人员都不熟悉新开发出来的程序,这就需要一个培训和一本操作手册,这个过程一般都由测试人员来做。为什么是测试人员来做?因为只有测试工程师最熟悉程序全部的功能。

  做培训或写操作手册也没什么,但是效果往往很难让人满意,无论你培训做的多么好或者操作手册写的多么详细,市场和实施人员都不会学。等他们工作时,就会来找测试人员帮忙了,客气点的会用个请字,不客气的就直接命令了,让你作一些本来该他们做的工作。比如帮客户做一些初始化数据,或者直接给客户实施等。除了测试工作外还要做很多本不属于自己的工作,再加上有些人员根本就看不起测试人员,工作中有意无意的欺负,经常把一下不相干的工作推了过来,于是乎测试在软件过程中沦为打杂。也许有朋友认为这个观点比较悲观,但是很多同行都有过类似的经历。尤其是刚开始做测试工作的朋友,因为自己刚入门,专业能力和公司的地位都不高,很难逃脱打杂的命运。

  看到这里,很多朋友可能会有不同的观点,他们会说那是那些软件公司根本不重视测试,在很重视测试的软件公司,测试工程师的地位还是很高的,他们能决定产品是否发布。如果测试工程师没有对开发出来的程序进行签字,程序就根本不能算开发完成。这种情况也很常见,随着自己工作时间的增长,自己的专业水平也随着增长,在软件过程中的地位也得到了很大的提高。在很长的一段时间内,我也拥有过软件项目发布的决定权,那时我认为自己就是质量卫士,是软件产品的看门人。工作了一段时间后,我对自己的看法产生了怀疑,因为这段时间公司软件产品的质量并没有得到提高,而且自己了承担了已发布产品质量的全部责任。开发人员提交的代码质量越来越差,他们认为反正由你们测试人员把关,有问题你们自然会提出来的,如果你们没有测试出来,那也是你们测试人员的责任。

  也许有人会说,那就测试做的详细一点,所有的可能都测试到,不要让有错误的程序发布出去。咱们姑且不论能不能做到测试所有的可能性和项目进度的要求,就算你在项目允许的时间内做到了,难道就能说这个软件产品的质量有了保证了吗?什么是软件质量?质量是客户要求或者期望的有关产品或者服务的一组特性,软件质量则是软件的功能、性能和安全性能满足客户的要求或达到客户的期望。测试人员大部分时间是要站在用户的角度上考虑软件的情况,但他们毕竟不是真正的客户,他们不能代表所有真正的客户实际的要求,软件产品就算通过了测试也不能保证软件质量。好的软件不是测试出来的,而是设计、开发出来的。测试人员不参与代码的编写和修改,当然也就不能提高或者降低软件产品的质量,软件质量来源于软件产品构建的人。

  既然测试工程师不是打杂的,也不是软件质量的保证者,那我们到底是做什么的呢,或者说我们测试工程师在软件过程中到底扮演了什么角色呢?我思考的结果是我们在软件过程中是一种服务的角色,我所说的服务绝对不是前面说的帮助其他人员做他们的工作,而是为整个软件产品的质量服务。因为能决定软件质量的是软件的构建者,他们可能包括公司的管理层、项目经理、设计人员、开发人员、实施人员、市场人员等等。由市场人员根据用户需求提出要做软件,然后管理层评估、组织立项,项目经理调研用户需求、设计人员设计程序架构,开发人员负责决体功能的实现,最后由实施人员为用户进行实施,并进行相应的技术支持。他们这所有人构成了整个软件过程,他们就是软件的构建者,他们在构建软件的同时,也背上了沉重的负担,那就是软件产品的质量。测试人员在整个软件过程的定位就是帮助软件产品的构建者解决软件质量这个沉重的负担。也就是说测试工程师应该在各个阶段帮助该阶段的对象做好相应的工作,具体的工作为:

  1、协调、组织各方面的专家对每个阶段的成果进行评审,包括需求、设计等。

  2、帮助预测和控制成本,以最小化的成本、时间来完成相应的工作,主要表现为督促项目开发进度的执行。

  3、快速找出重要的软件问题,也就是说要配合开发进度,尽快找出影响较大的软件问题。

  4、对产品质量提出总体的评估,是根据测试结果对软件产品进行一个尽可能客观的估计,而不是决定要怎么做出修改。

  5、确认产品达到了某种具体的标准,例如确定产品的质量是否能符合公司或客户那些等级的要求。注意,只用于确认并提供自己的意见,而不是决定是否发布。

  6、与其他人员协作实施培训,一般可以先培训本公司的其他人员,然后协助他们去培训客户,是协助,不是自己独立完成。

  7、帮助客户改进其过程,同时协助满足客户必要的要求。主要表现在软件产品与客户的实际要求产生偏差时,要查找不一致的原因,如果是客户的过程不合理就协助他们改进过程,如果程序不合理就要修改程序。

  在实际的工作中还要经常考虑自己当前阶段的使命,保证自己的计划不会由于过于偏重测试某一方面的问题而忽略其他方面。


TAG:

nightxxxx的个人空间 引用 删除 nightxxxx   /   2013-02-26 14:28:43
开发是测试的客户。所说的具体工作,很多其实不能应用于底层测试,最低也要测试leader才拉的动,更多只是辅助参与,给出测试方的建议
leileiyu1989的个人空间 引用 删除 leileiyu1989   /   2013-02-20 17:15:36
5
左右子曰 引用 删除 mkatsoho   /   2013-02-01 11:28:48
参考文献 http://www.51testing.com/?uid-363907-action-viewspace-itemid-834608

点评(不喜欢请忽略:)你提到的几点
1、协调、组织各方面的专家对每个阶段的成果进行评审,包括需求、设计等。
这是PM或engineering prime的职能

  2、帮助预测和控制成本,以最小化的成本、时间来完成相应的工作,主要表现为督促项目开发进度的执行。
其一测试成本只是冰山一角,其二开发代码的成本非测试部门可以预测和控制,其三督促和项目控制的职能属于PM,所以。。。

  3、快速找出重要的软件问题,也就是说要配合开发进度,尽快找出影响较大的软件问题。


  4、对产品质量提出总体的评估,是根据测试结果对软件产品进行一个尽可能客观的估计,而不是决定要怎么做出修改。
就是常常到最后时刻,QA还在忙着,或者是一个迟来的评估报告,或者是无胜于”聊“。一旦评估结果是不建议发布,你的manager敢公布吗?他的manager会同意吗?通常为了更”易读“,我们只在被删减之后的features基础上做评

  5、确认产品达到了某种具体的标准,例如确定产品的质量是否能符合公司或客户那些等级的要求。注意,只用于确认并提供自己的意见,而不是决定是否发布。
对滴呦。你有这样落实到number的标准码?这些numbers谁同意了呢?

  6、与其他人员协作实施培训,一般可以先培训本公司的其他人员,然后协助他们去培训客户,是协助,不是自己独立完成。
当然 不过让你负责业务不可。

  7、帮助客户改进其过程,同时协助满足客户必要的要求。主要表现在软件产品与客户的实际要求产生偏差时,要查找不一致的原因,如果是客户的过程不合理就协助他们改进过程,如果程序不合理就要修改程序。
需求管理啥时候是你QA的工作了?产品经理咆哮ing。客户的过程不合理,你真的能搞定客户,那是咱家开的?有,但鲜见。
左右子曰 引用 删除 mkatsoho   /   2013-02-01 11:13:12
-3
Joo_珠的个人空间 引用 删除 Joo_珠   /   2013-01-31 15:13:42
5
北方的郎 引用 删除 吼吼哈哈   /   2013-01-31 12:26:31
5
 

评分:0

我来说两句

日历

« 2024-05-05  
   1234
567891011
12131415161718
19202122232425
262728293031 

数据统计

  • 访问量: 28694
  • 日志数: 46
  • 书签数: 2
  • 建立时间: 2012-07-31
  • 更新时间: 2013-06-06

RSS订阅

Open Toolbar