你是不是一个好的测试工程师?

如何评价一个程序员是否优秀一直是一个很有争议的话题。

先说一个真实事件,国际化项目,最开始都是由产品经理在excel中管理翻译,迭代过程中如有增删改,就把增删改的部分标记出来,提供给开发,开发再对应更新多语言的资源文件。这个过程中需要产品与开发在中间倒一下手,很容易出错和遗漏,尤其是频繁更新时。为了方便对多语言翻译进行管理,前端同学写了一个多语言管理后台,取代了原先的exel表格,主要具备两功能:

  1. 产品经理可以先在test环境改,改完提交就生效,所见即所得。
  2. 提供了同步到beta和prod环境的功能,不需要每个环境都单独改,免得又改的不一致。

前端让测试同学帮助测试并提点建议,我提出几点建议:

  1. 在提交和同步前增加确认环节,提示本次增加,修改,删除的内容,经提交人二次确认后再提交(如有可能,可以做成由第二个人审批)
  2. 同步到beta和prod环境时,提供检测功能,如果有未翻译的key,提示风险或拒绝同步
  3. 提供备份恢复(或简单版本管理)功能,万一修改后的内容有问题,可以快速加回滚

哈哈,综合下来,感觉越来越像一个配置中心了。

前端同学说你这么一来,功能就复杂了啊,我是不是还要做个用户管理和权限体系,只有指定的用户有权限发布。后来又有后端开发加入讨论,最终讨论的结果不谈。主要是中间我提到,目前其他兄弟部门的多语言后台管理系统没有同步功能,都是各个环境单独修改,很容易遗漏,导致线上有很多漏翻的问题,于是测试同学为了保证多语言质量,写了一个检查工具,主动扫描线上的多语言资源文件,发现了很多漏翻的问题,极大的提高了测试效率,保证了语言测试的质量。这个同学在完成提效OKR的同时,也被提名微创新奖。如果你不实现这个同步功能,就会面临和兄弟部门一样的风险,那么就需要我去写一个工具来做这个检查,反正不是开发做,就是由测试来做。然后我想了一下,开玩笑说:“你还是不要做这个功能了,留给我来做吧,这样我的OKR上就有东西可以写了,如果你把这些都做了,不出问题了,我的价值何在?我只是在这里提了一个建议,这个建议的价值或许与我做一个检查工具是等效的,但是公司会因为这个建议而给我高的绩效分吗?又有谁会知道我曾经提过这个建议?

虽然是一句玩笑话,但却是说出了研发过程中的尴尬,大家为了OKR,为了有亮点,有时候明明可做更好,却要故意做的烂一点,为后续改进留有余地。即使没有问题,也要人为制造一点问题出来。如果一个产品线长期没有问题,那么这个产品线也基本不需要人再维护了,人员都可以优化掉了,只有有问题,才需要人去解决,才会招人,才会长期繁荣。从而推理出,没有问题的产品,不是好产品(可不可笑?尴不尴尬?)。

回到测试,测试工程师的价值如何体现?一个好的测试工程师,是将问题扼杀在摇篮里,还是事后写工具发现问题?

回答当然是两者都有价值,只是问题发现的阶段不同而已,而且从软件开发项目管理理论上来说,问题肯定是发现的越早越好。但是问题的关键在绩效评价上,老板都希望用数据说话,你说你做的好,空口无凭可不行。然后提前发现问题(提出建议)是不容易被量化的,而事后发现的问题(bug数量,线上故障数量)是可以量化的。

说到这里,我的结论是啥?其实我是没有结论的,只能感叹:发现一个好的测试工程师真的很难,发现千里马需要伯乐,大家都说千里马难寻,但也有可能是没有伯乐。

引申一下,在可以量化的指标中,很难通过某一个指标来体现一个程序员的好坏,比如:

  • 以单位时间内的工作量(代码量)来区分?单位时间写的代码越多就越优秀吗?显然不是,优秀程序员的十几行代码或许比一个普通程序员的几百行代码更高效。
  • 以交付时间?同样的任务,谁完成任务的快,谁就更优秀?或许吧,但任务按时完成了,并不代表代码的质量高和性能好,对吧?
  • 那以质量为指标呢?或许是个不错的选择,但是如何评价软件的质量呢?又是一个头大的问题,以bug数量来评价?bug少的代码,质量就一定高吗?万一是测试没测出来呢?或者有人代码写的少,所以bug就少,代码写的越多的人,出bug的可能性就更大,这样一来,程序员都不写代码,那也就没bug了,是不是质量就最好了呢?
  • 按照线上故障数?如果是前人留下的坑呢?你在别人的屎山代码上做的修改,结果一上线就报错了,你发现了前人留下来的隐患,然后那个人早已不在这个公司了,锅却留给你来背,这时候你是不是想骂街?
  • 有同学说,同行评价啊,按口碑(这就是360度环评)。唉,这想法很不错,但实践起来也是有很多不足之处。如果大家一团和气,一起骗老板怎么办?这恐怕是老板最不愿意看到的。另外,有的程序员写代码不怎么样,但天生会搞人际关系,很会拉选票(当然这不是贬低,他可能适合做管理)。而相当多的程序员大牛,都非常有个性,不希望被束缚,所以在人际关系这方面不怎么上心,结果就有可能在评比中吃亏。

综合下来,评价一个程序员真的是很难,要各个方面综合考虑,而不能参考某一个指标。

你可能感兴趣的:(管理,质量,软件质量,质量管理,绩效OKR)