匿名职言 关于业务部门的测试团队进行测试工具开发这件事

张浩 · 2022年11月22日 · 最后由 田志强 回复于 2022年12月02日 · 5084 次阅读

5 年前公司横向技术支持部有专门的测试部,主要从事测试用例工具、测试环境发布工具等开发,后解散。
负责人和部分人离职,部分人拆入其他部门,原先的工具就随着时代变迁及无人维护逐渐被业务部门的测试诟病。

当时,我们业务部测试领导决定自己根据自己需求开发自己的一些工具,着手开发后沿用至今,也共享其他部门使用。

这几年,技术支部也吸收了一些解散部门的测试,另外社招了一些技术背景测试。

CTO 今年开始着手技术支持部的工作,准备在整合开发、测试、运维做一些 devops 的工作。技术支持部老大也和我们部门相关人开会,主要意思是我们的一些工具本来应该是他们开发的(比如测试环境发布系统及测试用例管理、版本跟踪工具),比较惭愧;另 1 个就是我们开发的工具已经给很多部门使用了,需要统一管理,你们业务部门平时业务也挺繁忙的,可以在公司内部进行开源,有专门的部门维护比较好。

说了这么多,以上都是背景......然后下面是吐槽。

1、测试工具已经开源半年了,也没见他们有过更新,更新频率反而不如自己抽空维护

2、其实这个工具最早是希望技术支持部去开发的,当时都以无时间安排,先用老的等等原因退后了(技术支持部这几年开始涉及一些纵向业务...)

3、有次我们部门领导需要汇报,和我们讨论下规划,我们计划和开发在精准测试上做一些工作。领导不好意思的说,她被其他人提醒了,如果说这个,上面领导会认为我们的业务测试工作不饱和,那么我们只能改成建议核心技术部门帮忙在这块上能提供工具或平台支持。但什么时候完成,按以往的情况,谁又说的准呢?

共收到 4 条回复 时间 点赞

我觉得,在业务测试团队做工具开发的事情,大概率会是双输。
业务测试团队的工具开发同学最终的结局都是跑路,根本原因是绩效不稳定,定位模糊。做着相对有技术含量,而且一般也比较苦的活,还一直被其他团队吐槽;年年想着新造一些什么轮子,半年做大盘,半年做自动化,再来半年做 cicd,这些是 0-1 的蜜月期当然很开心,剩下就是推进落地和持续优化,痛苦期开始了:老板觉得没产出,做得人觉得没发展,看着业务测试同学天天需求测得飞起,无脑好绩效,跑路是分分钟的事情,当然这类测试开发跳槽涨薪也比较多。
所以,组建单独的工程效能团队,专业人做专业事是最好的,如果现在在业务测试团队做工具开发,听哥的,尽早转工程效能开发,或者安全/性能/稳定性的专项 sdk 之类,总之就是把自己放到定位是开发的团队中去。说难听点,你不是测试老板的基本盘,只是他的 KPI 工具。

2楼 已删除

确实有点难受,测试自己做点技术钻研可能不那么被提倡,而且很多时候还是自己业务抽了不少时间

有同样的经历,虽然你很想做起来,奈何努力的只有自己

我们公司测试工具等相关的东西还依赖开发帮忙弄。然后做出来的压根不符合测试的使用习惯,难用的要死

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册