|
应该怎么来衡量一个测试人员的能力?一直是群里的争论焦点。
很多人问待遇都喜欢这样问:“我工作×年,会×××、×××工具,在广州、上海、北京能拿多少工资?”我想他们已经把用工具摆在首要位置。确实,对于外行人来说会用自动化的测试工具是件非常了不起的事情(我没用之前,觉得QTP简直是奇迹的)。认为会用工具就是很大一筹码。个人认为全不然。
从整个软件生命周期来看,测试从需求调研工作就要展开,到产品完全交付才算结束(有些可能还有后期维护)。
1、旁听产品组于客户的每次交谈,对需求文档的检查,包括最简单的错别字检查、需求正确性检查(在这暂时不讨论了,觉得我们公司对这点做得还是不错的,以后可以拿出来分享下)。
2、参加架构组的设计活动,这里的参加不是要测试人员真正的去设计什么,而是参与他们比较重要的会议、讨论,了解软件的总体架构、数据库设计(数据校验占了测试工作中的很大一部分)。
3、在上面2点活动的同时可以开始根据项目计划编写测试计划、随着需求、设计的完成一步一步的完善测试用例。如果是没有经验积累的公司还可以趁这个机会确定规范、相关模板。
4、开发有一定的成果后,开始按照测试计划、测试用例展开测试工作。
5、缺陷跟踪,及时回归开发人员修改好的bug
6、需求变更时及时更新测试用例。
7、在系统稳定后开始自动化回归测试、性能测试。
8、验收测试(客户体验测试等等)
从上面的工作看来,自动化测试、性能测试都只是在系统成熟后才展开的工作。测试人员更多的精力时放在这些之前的手工测试上。所以我认为下面才是测试人员能力衡量要素:
一、编写测试用例的水平,一个质量高的测试及时给刚入门的新手来做也比“高手”顺手就测的效率高。
二、对缺陷跟踪的能力,这个可能包含得会比较广。比如怎么分配bug、怎么样在第一时间回归bug、怎么样说服开发人员修改他不愿意改的bug(总不能老拿头头来压他)、怎么样给出缺陷报告等。
其他的用什么工具、用得好不好都是给你锦上添花的筹码,而不是你开高工资的凭据。
以上说的可能比较适合稍以项目为主体的公司,因为测试负责人和测试执行人员分工不是很清晰,也比较符合国内现状,当然不包括哪些把测试人员当全才——配置管理、DBA、客服、培训要求测试人员身兼数职的公司。
个人观点,只是想跟大家广泛讨论,拍砖的请轻点~有点怕怕……
|
|