第一眼看去,楼主首先年龄应该不大,不然基本不会有大厂的面试,第二,基本面较佳,从经验到学历,从面的公司也能看出来,虽然大环境确实大不如前,但大浪淘沙,是金子总会发光,继续加油
工资都发不出了,后面就不是很乐观了,比较实际的,两手准备,一方面修改并开放简历,开始投递试水,根据投递情况总结调整自身能力和经验定位,并体现在简历上,一方面开始刷题,有针对性了解一些测试工具、理论和框架,并尝试在工作中应用,方向上可以往业务与技术结合的方向上靠,并从过去经历中挖掘相关经验体现。
想起近期一次领导面关于加班观点的一个问题
问:一个人能否成为优秀的人,是取决于什么
答:量化的角度看,取决于把时间花哪了
问:对,所以正如成绩好与不好的学生,造成差异的不是课堂上共有的时间,而是看课堂之外学习花的时间,职场也是一个道理
答:这是很重要的一方面,但除了(拼时间)这个因素之外,对于学习方法的总结思考,也很可能是造成效率差异一个很重要的因素,而能不能主动去想到这个点,背后本质还是思考事物的思维模式,比如,课后学习 5 个小时的,就一定比学 3 个小时的成绩好吗
。。。
结果:领导面挂了
相信这是很多测试开发都会面临的问题,关于这个有几点感受:
【谈谈问题】
【谈谈现状】
【谈谈思路】
哎,又摸鱼了
个人看法,测试工作总是需要的,但是不是意味着都需要专职测试来做,观点如下:
【不需要理由】
1、首先,目前整体而言,不管是叫测试还是质量保障,还是偏支持性的工作,即成本部门,而支持性分工在不同业务场景中,其实就意味着不一定是必需的;
2、然后像一些研发小团队,成员综合能力和自驱力都比较强的,然后交付的业务目标也是比较明确的,确实可以不怎么需要专职测试,而是开发自己可以做测试,甚至还可以做的更好,这是小团队、业务目标明确的情况;
【需要理由】
1、而一些比较大的复杂性系统工程,或者客户目标也可能经常变动的那种,还是需要有专职的分工,这个主要是出于一定业务规模下团队协同效率考虑,特别像不少实体产业领域,严格组织架构下较低的流动效率,技术架构中新老系统并存,实际特殊情况很多,比起追求更新更快变更交付,更看重业务系统的稳定,这种会需要;
2、云原生背景下架构升级带来的测试挑战,很多原先传统功能测试能力可以覆盖到的,也会越来越力不从心,但架构越复杂,通过测试保障质量的工作就越是必要,所以越来越多企业对测试的要求,也是不断往自动化、测开上靠,相当于变相在倒逼测试要求升级,这个角度看,角色是需要的,但是是以另一种要求更高的形态。
【补充】
综上,因为技术的演进带来角色分工的变化,这点不仅对测试,其实像运维、研发等都有同样的挑战及困惑,但可以观察到,产出性工作相对支撑性工作而言,更难被工具替代和冲击(测试、运维、研发、产品等可按该维度代入对比下),像测开,偏技术路线的,其实更多是通过工具化、平台化形式,将测试能力赋能给其他人使用;然后像 BA/PO/PM 等,也有不少测试出身的,偏业务路线的,则是通过拉通底层技术,指导业务设计,都是属于有产出价值、产出效益的,这里既可以是经济效益,也可以是社会效益都行。
当然,该问题还可以有很多分析角度和职业方向,因为每个人都是不一样的,暂时想到这些,欢迎补充。
已阅读