• 挺全面的👍

  • 感觉是提前通知你,公司有可能要进行缩编,让你提前做团队优化准备😂
    可以直接找领导沟通确认下,各部门、各团队缩编比例,提前进行人员锁定以及 HC 争取活动。
    测试裁的少,别的就裁的多,裁员多少是可以争取的,做些活动还是有希望的~

  • 需求迭代,我理解的是一个新的需求文档,并不会复用吧
    而且这种情况下,每个版本的需求都不一样,本身只是简单的用例维护,现在会变成需求及用例维护,但需求维护方并不在测试,最后一定是混乱的
    这样也不利于维护,由于需求而产生影响 的用例

  • 需求是迭代的,如果没有完整的用例库,后面就没办法整体维护。

  • 😅 我感觉 ,这个副业可以转成主业,肯定比现在主业强啊。。。

  • 做一个资源排期表,维度为日期、资源。
    通过资源排期表,实时调整每个资源情况,也可以拿 着这个数据,与各项目进行周旋。
    资源就是这么多,能做的事情也就是之么多,要么串行,要么增加资源。用数据说话

  • 扒代码分析接口逻辑或与前后端研发确认接口规范,明确关键参数,以及参数对应的业务处理逻辑

    • 根据具体业务逻辑来确认需要覆盖的参数场景
    • 根据前端调用规范,构造参数场景

    接口 20+ 参数,一般都是数据采集类型吧?确认下接口用途,采集类型 的话,只需要关注关键参数逻辑,确保所有参数都能采集就完事了

  • 😅 我们打个补丁去

  • 谈一谈今年的 TesterHome at 2022年11月29日

    大环境是一方面,新技术的接受度也是一方面,比如:前些时候百度、蚂蚁的干货分享

    还有一方面,老同学上升了,新鲜血液少了

  • 有两种情况:
    1、非常熟悉业务对应接口,对于接口数据源也非常了解(经常负责的对应业务接口,理论上应该是完全能够掌握,数据来源了,从上层接口还是数据库进行获取数据,心里有数的)

    • 在需求出来后,第一时间就可以和研发一样,结合需求同步进行初步接口分析和用例设计
    • 研发接口文档出来后,结合自己的分析情况,进行查缺补漏。研发分析的不代表是全的、对的
    • 要求前、后端开发对接口文档达成一致后,完善用例

    2、能进行接口测试,没办法自行分析接口伪开发需求,比如现有接口是否能满足?新的需求用到的数据,需要从哪里获取之类的

    • 梳理业务点
    • 研发接口文档出来后,结合业务点,确认接口是否满足
    • 编写接口测试用例
  • 在创新或 KPI 设定时,针对这块内容要进行完整性规划的, 比如前期调研、后期维护、使用期间的各种问题解决、指导相关、工具或平台的推广,各阶段对应的是长线成本还是短期成本,工具或平台最终目标,预计成果。

    KPI 或创新的完成与实践成果挂钩,最终只考核落地效果,与实际收益进行挂勾,达不到预期效果的扣除绩效、奖金。达到预期的提升绩效、奖金。

    当为了做而做,无意义时,就没有人再去做门面了

    当然一个有意义的工具或平台,在后面投入成本进行维护,也是有必要以及公司认可的行为,这也是属于工作内容的一部分

  • 好久没发帖了 灌个水 at 2022年11月25日
    仅楼主可见
  • 两个类型是不一样的吧,一个是数组,一个是字符串

  • 实施和客户对接:
    测试是最熟悉环境部署相关的,在很多传统企业实施也是可以由测试进行的,产品上线后,经常是测试进行演示以及实施部署

    测试同时是最接近客户的群体,本身就代表着客户,可以借这个机会放大自身优势,和客户一起来探讨产品设计,逆推功能有效性以及适用性,可以尝试配合产品一起挖掘新功能,新产品

  • 测试环境和生产环境虽然是隔离的,但既然被攻击到,还是有必要看一下的,确认线上是否做好了安全防护。
    但应该是针对线上环境,一般情况下,测试环境和线上环境一定是有拓扑差异的。

  • 小白刚学测试 at 2022年11月17日

    如果是转行或准备培训入行,建议直接考虑研发体系,很多人公司质量效能平台也都是研发在负责
    上岸的话,也是个好去处😂
    但是测试行业未来还是有发展的,只是卷罢了。。。不是卷开发就是卷运维,都是卷😂

  • 仅楼主可见
  • 我是觉着不妨,往大了整 ,触达的覆盖范围大一些,这样测试阶段才更通畅一些,像:

    • 版本需求确认(结合研发、测试初步预估排期,提前确认本次能上线的功能)
    • 排期收口(除了测试排期,把研发排期也纳进来,结合上线日期、测试方案,统一协调)
    • 范围收口(与研发达成共识,针对某些特定功能,影响范围收紧,测试无法进行的测试可以移交到研发进行)
    • 版本收口(针对上线的内容,制定版本准入策略) 不过还是要结合业务实际情况进行,建议全流程 ,测试毕竟偏向于后面阶段,需求产出的阶段开始把控,后面阶段才能更通畅
  • 建议重点考虑关联节点的约束和流程,配合这些节点,调整测试规范和流程
    其实就是约束各个协同节点,尽量减少测试繁琐度,提升测试流畅度😁

  • 😅 行业通病吧,大家只关心自己负责的部分,一般讲到自己负责部分的时候,关注度最高
    还有一种情况是,真的在处理问题,工位的时候都没有时间看消息,处理问题,开会的时候抽时间解决问题,这种也是非常常见的
    不过在讨论 kpi 呀 OKR、奖金相关的时候,大家一般都是厮杀状态😂

  • 在团队内尝试引入一些新鲜技术,让大家分别选择进行调研和实践,然后推动大家在项目中落地
    参与调研的同学,调研完成都进行课题分享
    也可以自行申报课题分享,经常分享的同学,给与考核加分支持

  • 缺失了公司名称、联系方式哦,补充 一下吧 楼主

  • 上面明明说的是:
    要学哪种语言,没有什么好纠结的,主要在于你要干什么?你的目标是什么。
    不知道哪个说法引起了歧义😓

  • 没太懂,但最终你一直在说的是走上层还是下层好,对应的不就是所谓的技术体系嘛?
    每个公司核心技术体系都是不一样的也是事实吧?最终决定于公司从事哪个方向、哪些个领域吧?
    但硬说是行业发展趋势?完全不搭边呀。。。