“大多数人可能是不甘心,觉得桃子被人摘走了”
这么想是正常的, 正常人都会有这种感觉得。 你可以冷静下来权衡一下当前的局势。 如果做管理是你的刚性需求(硬性的职业规划),并且你也可以在外面公司找到一个管理岗, 那你可以考虑掀桌子不干了。 如果不是我就建议你调整调整心态, 先在这边好好干下去。
相处挺融洽的, 我成了他的心腹。 这玩意我自己知道自己不适合做总监,也没那个野心,做了也做不好。 所以我过的了自己心里这关。 大多数人可能是不甘心,觉得桃子被人摘走了,所以能过自己心里这一关很重要。 当然也要对面不防备你, 要是在大厂,可能人家来了第一件事先架空你,边缘化你, 换自己的嫡系过来。 所以这个是双向的, 我自己要甘心, 他也要信任我。 所以我们后来将近 6 年时间相处的都很融洽。上周末的时候我俩还一起吃饭呢,虽然我都已经离职来腾讯了。
我在第四范式的时候, 就是亲手把我领导招聘进来的, 后来我是 leader, 他是总监。 我当时想的很开, 我不适合做管理, 招他进来就是为了做质量部总监的。
你体会一下一个人同时负责几个产品,对着 20 几个开发就明白了。 根本没那个心情和时间写用例,就是直接上。 或者简单写写 checklist 或者思维导图。
而且我自己也比较特殊, 现在需要我动手测试的都是很底层的东西, 没有图形界面,都是用代码测的。 所以写个鬼的用例, 我的代码就是用例。
现在很多人都这样吧, 虽然我在大厂但流程也没那么规范。 都是怎么快怎么来, 用例评审都很少别说写用例了。 直接写代码更符合我们的喜好。 而且一个人可能对着十几二十几个研发的, 哪有时间写用例。
也不全是, 只要不是纯管理岗, 就还是需要去执行一些测试工作的。 现在一些难度比较大 ,或者很底层的一些测试, 都是找高阶的测试开发人员去测的。 等把平台工具都建设好了, 才会交给其他人。
如果我说我已经几年没写过测试用例了, 大家是什么感觉 。 一个是我一直测试的模块比较特殊,都是可以自动化的,所以我的代码就是测试用例。 再一个也是因为忙起来没那个功夫和心情老老实实的写用例, 直接就上手写代码。
行情再不好也总有存活的培训机构的, 只是去上班,不是去创业。 就看到时候培训机构的面试能不能通过了
烂了的意思是?
先能干一年是一年, 外面的行业真没有这一行挣的多。 所以能多干一年都是赚的, 然后在干的过程中慢慢的去找适合自己的方向, 为 40 岁以后做准备。 我基本就是这么做的, 我现在觉得做培训讲师还是挺适合我的,也许有一天我岁数大到了没有互联网公司接收我的时候, 我就专职干培训去了。
我觉得有几点吧:
我个人不太看好 AI 生成测试用例,AI 精准测试这些方向的。 行业中没听说过有非常成功的案例。 搞这些的成本也很高, 你需要大量的很规范的产品文档和用例文档。 但这些都不是现在的国内公司有精力去搭建维护的。
有道理, 研究一下
各个大厂现在都这样,裁员,降本增效,之前我领导不小心 把我拉到一个大老板们的会上,大老板们就对着项目营收数字定团队规模。 有多少盈利对应多少人,如果人多了就减员。 很冰冷很残酷,但老板也说没办法,公司就是这个规定。 所以我们这种还盈利的产品算好的了, 基本没怎么裁员, 都是自己离职的,只是不怎么进人了。 像其他亏钱的产品, 指不定啥样了就。
安定在一个地方了, 就不是特别想走了, 我也有惰性 ,现在收入也不错的,去外面风险也不小。 所以先不动弹了
嗯, 有的
嗯那,十分卷了
这周日开,欢迎参加哈
真的花不了几个钱。。。。百川的最贵的模型, 也才 1 毛钱/千 token。 项目上连这点钱都不愿意出么。
目前已经都有现成的方案了, 你去百川也好, 百度的 appbuilder 也好, 阿里的千问也好, 都有大模型 + 知识库构建的能力了。 你需要做的就是整理好专业的文档上传到他们的知识库里,然后付费使用就行了,这玩意也不贵。 为啥要自己撸一套。 你要知道这东西它不是攒 3,5 个人就能搞定的。
就是怕继续跌下去,所以止损
我在天津买的房子刚卖出去, 腰斩了。 心疼的我几晚上没睡着
跟恒捷说的一样, 只有很少一部分人是在这种不碰业务的测试开发部门,我上面也说过大部分测开都是在业务里的, 自己开发工具, 简单的交给外包用, 困难的交给子公司或者自己用。 现在大厂业务部门里也基本没有那种只开发工具不做测试的岗位了。 我自己也是, 别看我现在级别上去了, 但是我还是需要在一线搞测试的。
@ZFW 的意思是: 大厂的标准模式就是一个正式的带一堆子公司和外包的模式。 正式员工很少来执行手工测试用例了, 只有一些难度比较高的,无法让外包和子公司人员来执行的测试会让正式员工来。 其他的工作正式员工主要是制定测试方案,开发测试工具,管控测试进度这样的事情。 所以按你的标准,大厂里正式的测试人员都是不务正业的。 你的观点过于极端了。
然后我的意见是业务里的测试开发挺常见的, 自己业务的测试工具自己来开发,简单的交给外包来执行,困难的交给子公司或者自己来执行。 完全不碰业务的测试开发即便在大厂里也是很少见的。就像我们测试模型是完全没有图形界面的,甚至连个 http 接口都没有,只能调 SDK 或者 gprc 和 trpc 协议来测试。 所以即便其实测试用例挺简单的, 就把数据给模型然后通过结果统计评估指标么。 但没有代码能力的外包人员, 你让他们写 trpc 调用实在太难为人家了。 所以我们正式员工来写工具,外包只需要按场景挖掘数据,审核数据,与算法人员讨论 badcase 等等这些事情。 这是一个在业界里十分有效的工作模式。 尤其是在降本增效的大环境下,已经是主流的方法了。 就算是那种完全不碰业务的测试开发,也是在一个单独的部门里, 他们负责的是大部门级别,或者公司级别的测试基础建设,并不是大家理解的随便开发个跟 pytest 差不多的框架,那是小厂子里的人搞过家家的手段,大厂里的这部分人要负责打通网络,环境,权限等关要(在大厂里,环境不是那么好搞的,不同的云里面, 不同的机房里,IDC 里,公有云,私有化,开发机,这些环境的网络可能都不通,权限可能都是不开放的,做测试的时候就需要有相关的基础设施来搞定这些,因为这不是给业务团队开发权限和网络来做的, 这事关安全)。 当然确实有些不误正业的地方跟过家家似的搞个类似 pytest 的框架,封装个前端就当平台的。 但在大厂里,人家测试开发部门就不是搞这些小家子气的东西的。
所以有一些人不务正业搞花活这种情况是存在的, 但别太极端, 还是有很多的测试开发在认认真真为公司提供价值的。
说的非常对