挺全面的
感觉是提前通知你,公司有可能要进行缩编,让你提前做团队优化准备
可以直接找领导沟通确认下,各部门、各团队缩编比例,提前进行人员锁定以及 HC 争取活动。
测试裁的少,别的就裁的多,裁员多少是可以争取的,做些活动还是有希望的~
需求迭代,我理解的是一个新的需求文档,并不会复用吧
而且这种情况下,每个版本的需求都不一样,本身只是简单的用例维护,现在会变成需求及用例维护,但需求维护方并不在测试,最后一定是混乱的
这样也不利于维护,由于需求而产生影响 的用例
需求是迭代的,如果没有完整的用例库,后面就没办法整体维护。
我感觉 ,这个副业可以转成主业,肯定比现在主业强啊。。。
做一个资源排期表,维度为日期、资源。
通过资源排期表,实时调整每个资源情况,也可以拿 着这个数据,与各项目进行周旋。
资源就是这么多,能做的事情也就是之么多,要么串行,要么增加资源。用数据说话
扒代码分析接口逻辑或与前后端研发确认接口规范,明确关键参数,以及参数对应的业务处理逻辑
接口 20+ 参数,一般都是数据采集类型吧?确认下接口用途,采集类型 的话,只需要关注关键参数逻辑,确保所有参数都能采集就完事了
我们打个补丁去
大环境是一方面,新技术的接受度也是一方面,比如:前些时候百度、蚂蚁的干货分享
还有一方面,老同学上升了,新鲜血液少了
有两种情况:
1、非常熟悉业务对应接口,对于接口数据源也非常了解(经常负责的对应业务接口,理论上应该是完全能够掌握,数据来源了,从上层接口还是数据库进行获取数据,心里有数的)
2、能进行接口测试,没办法自行分析接口伪开发需求,比如现有接口是否能满足?新的需求用到的数据,需要从哪里获取之类的
在创新或 KPI 设定时,针对这块内容要进行完整性规划的, 比如前期调研、后期维护、使用期间的各种问题解决、指导相关、工具或平台的推广,各阶段对应的是长线成本还是短期成本,工具或平台最终目标,预计成果。
KPI 或创新的完成与实践成果挂钩,最终只考核落地效果,与实际收益进行挂勾,达不到预期效果的扣除绩效、奖金。达到预期的提升绩效、奖金。
当为了做而做,无意义时,就没有人再去做门面了
当然一个有意义的工具或平台,在后面投入成本进行维护,也是有必要以及公司认可的行为,这也是属于工作内容的一部分
两个类型是不一样的吧,一个是数组,一个是字符串
实施和客户对接:
测试是最熟悉环境部署相关的,在很多传统企业实施也是可以由测试进行的,产品上线后,经常是测试进行演示以及实施部署
测试同时是最接近客户的群体,本身就代表着客户,可以借这个机会放大自身优势,和客户一起来探讨产品设计,逆推功能有效性以及适用性,可以尝试配合产品一起挖掘新功能,新产品
测试环境和生产环境虽然是隔离的,但既然被攻击到,还是有必要看一下的,确认线上是否做好了安全防护。
但应该是针对线上环境,一般情况下,测试环境和线上环境一定是有拓扑差异的。
如果是转行或准备培训入行,建议直接考虑研发体系,很多人公司质量效能平台也都是研发在负责
上岸的话,也是个好去处
但是测试行业未来还是有发展的,只是卷罢了。。。不是卷开发就是卷运维,都是卷
我是觉着不妨,往大了整 ,触达的覆盖范围大一些,这样测试阶段才更通畅一些,像:
建议重点考虑关联节点的约束和流程,配合这些节点,调整测试规范和流程
其实就是约束各个协同节点,尽量减少测试繁琐度,提升测试流畅度
行业通病吧,大家只关心自己负责的部分,一般讲到自己负责部分的时候,关注度最高
还有一种情况是,真的在处理问题,工位的时候都没有时间看消息,处理问题,开会的时候抽时间解决问题,这种也是非常常见的
不过在讨论 kpi 呀 OKR、奖金相关的时候,大家一般都是厮杀状态
在团队内尝试引入一些新鲜技术,让大家分别选择进行调研和实践,然后推动大家在项目中落地
参与调研的同学,调研完成都进行课题分享
也可以自行申报课题分享,经常分享的同学,给与考核加分支持
缺失了公司名称、联系方式哦,补充 一下吧 楼主
上面明明说的是:
要学哪种语言,没有什么好纠结的,主要在于你要干什么?你的目标是什么。
不知道哪个说法引起了歧义
没太懂,但最终你一直在说的是走上层还是下层好,对应的不就是所谓的技术体系嘛?
每个公司核心技术体系都是不一样的也是事实吧?最终决定于公司从事哪个方向、哪些个领域吧?
但硬说是行业发展趋势?完全不搭边呀。。。