转--如何给予测试人员合理的考核?

上一篇 / 下一篇  2011-07-26 11:30:32

如何给予测试人员合理的考核?

  有人问如何考核测试人员,我回了几个帖子,下面就是我回帖的内容,可以代表我对此事的一些看法。

  一、测试人员的工作评价比较的难办,因为测试人员没有具体的工作产品产出。

  测试人员一般做的也就是测试用例的编写和测试缺陷的提交。而这些可以说都不是看技术,而且看职业道德。所以我更多的认为,测试人员最重要的是责任心,是想做测试而不是开发什么的。一个测试人员提出1个问题或提出10个,对软件最终的质量影响可能并不像大家想的那么严重。 如果真的要考核,只能从工作产品考核,提交的缺陷不可能做为考核的目标,因为分配的模块、测试人员的视角、开发人员的技术差异等都可能会造成相当大的振荡。所以通常都是从测试用例的角度来进行评价。 这样可以换个角度来说关于测试用例。

  测试用例可以说是最变幻莫测的东西,因为至今没有一个严格的标准和理论来阐示测试用例的编写(记住,是测试用例, 不是别的什么)。而且测试是软件工程收尾的工作,很难有大的时间和精力去编写详细的测试用例,但简略的用例根本用不上,只能提供一个大概的思路。并不合适考核的条件和标准。 所以真的想考核,可以,把你们单位的各种关系理顺,完全按照软件工程的方式一点一点的来(RUP,CMM等都可以,因为里面的工作都很容易度量),如果不是按照这样,凭空的说考核测试人员,还不如经理直接拍脑门决定好了。

  二、上面说的多,但中心只有一个:想考核,就必须有一个可以比较的标准,所以首先要想好自己的公司是否存在这么一个东西。如果没有,还是不要考核好了。用bug数考核测试人员,就像用代码行数考核程序员一样可笑。

  三、现在别说测试人员,就是程序员又有几个公司可以做到让大家都满意的考核?

  测试应该可以说都是在摸着石头过河,有理论,但实际很难做。所以我一再强调测试人员的责任心,因为测试工作本身几乎无法度量,就像你写的,做一个小时和做8个小时从工作成果上并不能很好的体现出来。为什么没几个愿意做测试,因为测试即幸苦又无聊,工资也比较少,成果还总被忽视。其实谁做的多少、好坏,大家心里都有杆秤,只要在奖惩的时候,经理能做到一碗水端平,即使没有实际的比较标准,大家也不会过多的说什么。管理对的是人,不是机器,不要妄图制定一个完美的标准,即使有,还会有人不服气的。只要心中无愧,做什么随便让别人去说好了。

  四、前两天才看到有人在讨论测试用例写的时机,觉得很有道理。

  如果按照标准的软件流程,测试人员可以参与到需求、设计阶段,测试用例当然比较的容易写。 但现在更多的情况,是程序开发完毕了,才交给测试人员,这样如果写用例,一是时间的问题,二是对程序不一定熟悉。所以说真的,写测试用例有些不和适宜。 而最常见的是测试完毕后补测试用例(嗯,怎么和程序员一样了,鄙视自己和大家,哈哈),这样一般都是为了应付上面和客户用的,只能说是一个总结,因为问题都找出来了,自然容易按照问题写用例,可以比较的完美。 所以我建议写测试思路,特别是有多业务流程的时候,这样做不容易遗漏。

  至于那种白痴照着做都可以发现问题的测试用例,反正我们是没有这个时间和精力,而且很多的时候,觉得测试都是一门艺术(再鄙视自己一次),发现问题更多是直觉(也许是错误的操作),这些都是用例无法表达的。 如果真要写,可以写一个简单的,随着测试的展开,对程序的熟悉认识再逐渐的补充。这样测试的差不多了,用例也基本写好了。 测试用例其实最难掌握的就是一个度,写到多详细,而这一般和测试时间呈线性关系。


TAG:

引用 删除 tingking8882   /   2011-08-03 09:59:10
-5
引用 删除 tingking8882   /   2011-08-03 09:58:50
看到 测试是收尾工作时,就知道这篇文章没有意义了。再见
 

评分:0

我来说两句

日历

« 2024-03-26  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 9424
  • 日志数: 19
  • 建立时间: 2011-02-14
  • 更新时间: 2011-09-13

RSS订阅

Open Toolbar