有没有发现现在招聘测试工程师的JD,基本都涉及开发内容了?比如:
是不是感觉不会写代码?就干不了测试了?
事实上,“面试要求造火箭,日常工作拧螺丝”之类的事情比比皆是。
即使日常工作只是“点点点”的验证工作,面试时候也得笔试,在纸上写个排序算法什么的。
软件测试已经走入一个误区——“非代码不可”!
换言之,软件测试目前一个趋势,测试工程师什么角色都必须写代码。
写代码,增强自动化程度,让计算机完成重复动作,本身无可厚非。但是一旦过了,变成“必须写代码”,就是当前软件行业的一个误区。
“非代码不可”的误区形成,有几个原因:
测试不受重视
这个话题相信会引起众多测试人的共鸣。
请回答几个问题:
“公司里研发和测试人员的配比是多少?”
“软件研发周期是多久?多少时间留给测试?”
“软件上线后出现问题,第一个被责问的是哪个团队?”
几个问题,基本就可以男默女泪了。
测试团队必须体现出自己的技术性、专业性?还要量化地表现出来。
全面学习研发,跟着写代码,就是一个很直接的想法。
于是,很多测试人放下业务研究,拿起了IDE开始写代码…
测试团队负责人不懂测试
这也是一个现实问题,不少的测试团队实际负责人是R&D的领导,或者测试经理向R&D负责人汇报。
R&D的领导,99%是纯研发出身,也是不争的事实。
IT技术发展,分工越来越细化,研发和测试,本来就是两个不同的方向。
这就难免出现外行管内行的问题。
如果从纯研发人员眼光来看,代码量是衡量工作的一个标准,但是用这个标准要求、衡量测试的工作,则以偏概全了。
多数人,只能理解自己懂得东西,否则就套用到自己理解的范围内。
过分强调自动化
自动化测试,是一个好的方向,替代了很多人工劳动,尤其在回归测试方面,尤为重要!
但是,如果觉得“自动化测试”能解决一切问题,那么就言过其实了。
全面推广自动化测试,意味着相关的测试人员必须写代码。
- 怎么判断测试的业务覆盖率?
- 怎么判断异常用例的范围足够?
- 多少缺陷是自动化测试用例发现的?多少是人工测试发现的?
几个问题的答案,不言自明。
如果没有好的软件架构,自动化测试,尤其是UI自动化测试,绝对是疲于应付各种修改。
铺开自动化测试前提是,有个好的测试架构师规划。
综上所述
走出“非代码不可”的误区,软件测试应该回归本质:保证质量。
在测试这个角度,软件测试的本质是质量保证,一切能够提高质量的工作都是测试人员应该涉猎的,代码仅仅是其中一部分。
误区的存在,导致很多测试人员在为了代码而学习代码,并没有解决质量问题,甚至不懂业务。
更可怕的是不少测试人员既不关心业务,也不关心技术,而是整天琢磨着下一步转型成什么角色的工作。
就软件测试领域而言,接口测试、安全测试、性能分析……,很多工作真的不需要具体写代码。
人的精力是有限的,全面开花,往往意味着“十八般武艺样样稀松”。最终会面临35岁问题。
随着敏捷跟DevTestOps体系的流行,测试行业也开始慢慢发展,各种概念开始流行,测试人员对于未来的发展可能会迷茫,这个是可以理解的,但还是要有独立思考的能力,不要总是人云亦云,相信什么名人效应。
迷惘的时候,不妨思考一下事情的本质是什么,找到本质,也就有了方向。