前几天写了篇性能测试如何入门实践的文章,技术交流群有位同学截取了其中一段表达了自己的观点:性能瓶颈定位和优化,应该是研发来做这件事。然后群里其他同学纷纷参与了这个话题的讨论,表达的观点主要有下面几种:
- 现在技术岗位的职责已经没有明确界限了;
- 性能瓶颈定位优化研发来做,那测试的层次太低了;
- 测试除了做好测试工作,还应该做生产环境的根因分析;
- 如果没有专门的SRE团队,那性能根因分析就应该QA来做;
我观察了群里同学的发言,可以看到测试圈子整体的认知水平和职责范围相比以前,有了明显的提升。但还是有部分同学依然用原有的思维来看待测试这个岗位,心里不免有点戚戚焉。
这篇文章,我想聊一些我的看法,关于软件测试这个岗位当下的处境,以及未来的发展空间。
软件测试岗位和职责定义
话题要从软件工程说起,最初IT行业的分工,应该是从软件工程的角度分工的。从软件工程的角度来说,要研发交付一款软件产品,大概要经过需求、研发、交付三个阶段。而研发阶段细分的话,可以参考瀑布模型:
研发阶段主要分为需求分析、方案设计、编码实现、测试验证、运维发布五个阶段,然后自然而然出现了产品经理、开发工程师、测试工程师、运维工程师等角色。
从软件研发交付流程来说,测试工程师的岗位职责主要有如下几项:
- 分析需求:得到这个迭代需要测试的功能点;
- 设计测试方案:如何开展这些功能点的测试工作;
- 设计测试用例:功能点的最小模块,力求尽可能覆盖涉及的场景;
- 测试用例执行:执行测试用例,验证每一个场景的功能实现是否符合预期;
- 跟踪缺陷状态:发现bug、提交bug、跟踪bug状态、bug修复验证、关闭bug;
- 出具测试报告:对本次迭代的测试活动进行完整统一的说明,承诺经过测试满足产品设计预期标准;
软件测试工程师要干的事情主要就是这几项,大多数测试同学在大学学习的课程或者初入职场时,做的也都是这些事情。
如果IT行业的方法论和知识理念一直不变,商业活动和业务需求一直保持如此状态,IT技术一直不变,那么这些事情可以保持很久不变。
但是,无论是商业活动还是业务需求抑或IT技术一直是变化的,岗位职责也应该跟着变化。
不要被岗位限制了发展空间
近几年软件行业的变化速度在不断加快,从迭代模型、业务需求变更速度到IT技术都在变化。
- 迭代模型:瀑布模型、双W模型、敏捷方法、版本火车;
- 需求迭代速度:三个月、一个半月、双周、一周一版本;
- IT技术的变化:单体服务、集群服务、分布式架构、微服务架构、容器化、云原生;
随着这些因素的变化,行业对测试工程师的要求也在不断升级:
- 从最初的QC(质量验证)到现在的QA(质量保障);
- 从点点点到现在啥都要会(写代码/搭环境/线上跟进);
- 工作范围从测试环境向两头扩展(测试左移/测试右移);
加上当下如此低迷的就业形势,如果还固守最初对软件测试的认知,不主动学习提升自己,那很快就会被淘汰。我并不是在危言耸听,也不想加深大家的焦虑,近几年程序员“35岁失业”的梗甚嚣尘上就可见一斑。
IT行业的特点就是不断涌现新技术新方法,替代原有的老技术旧方法,这本身就是技术进步和生产效率提升的必然结果。今年爆火的ChatGPT,做技术的同学应该或多或少都有感受。
当然,如果只把软件测试当作一个谋生的手段,做不下去就转行做其他工作,也没错。从事什么行业,做什么工作本身就是个人的选择,没有好或者不好,也没有对错之分。
但如果想在这个领域,在软件测试这个岗位上不断的发展进步,那我个人的建议是:摒弃以往对软件测试的固有认知,不断提升自己的技术能力,不断扩展自己的职能边界,去做更多的能提升效率创造价值的事,才是一个合格甚至优秀的软件工程师该有的职场发展道路。
注意,这里的主语,我并没有说软件测试工程师,而是软件工程师。软件测试只是一个术语,不要将其当作一个能吃一辈子的岗位,成为一个能提高效率和提升软件质量的工程师,才是软件工程最初的理念:解决软件研发过程的不可控因素,聚焦于质量,构建和维护高质量软件。
标签:不要,迭代,工程师,岗位,仅限于,测试,bug,软件测试 From: https://www.cnblogs.com/imyalost/p/17605348.html