• 先调整好心态,多数时候未必自己就完全不行,只是简历上没有戳中用人单位的兴趣点,我的房东小我几岁小学没毕业,到我租到他的屋子的时候人家还有二十一套装修好散好味没租出去的,学历虽然是一道坎但并非绝对的。

    整理一下七年间的得失,想清楚自己能忍到什么程度,按这个标准,在简历中适当迎合一下人家公司的业务需求就行。

  • 感谢,我发现我对共性这个点理解偏了,基础服务类包括运营支撑之类的平台抽到中台是一个合理的考虑,之前我见过一个把上下紧密依赖的业务公共服务抽到中台的案例,结果是底层服务频繁迭代,导致上层业务进度和沟通成本失控,缺陷在业务下游被放大;汇报线也混乱,上游业务的运营策略要依赖中台的资源,结果导致中台和业务没办法协同,互相推责任,整体效率低下

  • 感谢分享,很有用,不知道我的理解对不对,我举一个脑补的测试部门的OKR实例大家帮忙看看:

    本周关注的任务:
    P1: 上月所有版本问题回溯分析
    P1: 本周版本回归
    P1: xx工具分享

    OKR当前状态:
    目标:提高发版质量
    关键结果:线上资损率25%(2500/10000)
    关键结果:月均缺陷率
    关键结果:持续改进措施覆盖率(版本覆盖率:37/50,资损覆盖率:1900/2500)
    关键结果:人员技能提升(新工具推广3/12团队)

    未来四周计划:
    推动所有团队的版本回溯
    工具推广应用
    检查预防措施执行情况

    状态指标:
    缺陷率持续下降
    人员单位产出增加

  • 部门架构上的划分问题并不是可以一笔带过的程度了:

    1. 中台和业务线业务重叠的部分责任如何划分?
    2. 业务线和中台都要快速迭代,但是中台的升级本身就会给业务线带来影响,如何能保证项目选择和快速交付的战略能够执行下来?
    3. 这个组织架构在结构上并不属于项目型架构,也不属于职能型架构,矩阵的划分上不仅有权责交叉还有业务领域的重合,怎么保证在执行组织级策略的时候,干系人之间能达成一个平衡,纵向的资源整合如何操作?
  • 可以设置跳过这个文件,在exclude path里面,但是这个方法是治标不治本的,完全无法预测这个类里面的方法什么时间维护过,会不会有数据类型的问题,遇到JAVA 11的新的安全策略会不会有代码编译失败等等等等问题。

    建议,如果是这个文件彻底不改了,类似于金融行业很多的Fortran工具类,直接打成二进制文件,也可以避免因为JDK升级导致的编译失败。
    如果还打算改的话,把风险暴露出来给相关的干系人,让开发那边给出整改的建议。

  • 😂 你可以考虑我们公司,我们需要各种骚气测试

  • 30岁,多多少少有一些沉淀了,无论是技术上还是阅历上;我个人认为在这个时间点,需要优先考虑的不再只是自己的能力基线问题,而是如何把自己的能力变现了,说直白了就是如何用自己的能力和阅历去服务和成就更多人,下面几个方面是我看到别人做的:

    1. 测试框架和工具的开发
    2. 共性问题的总结和流程的优化
    3. 方案的产出
    4. 辅助新员工提升
    5. 对外支持,比如投标方案质量保障的可行性、咨询方案中灾备和实施等方案的问题、客服反馈的问题中的共性问题如何提高解决和应对效率分析等等
    6. 理论的学习,主要是项目管理和质量管理的,工科的技能在解决具体问题是有效果的,但是如果放在更宏观的角度去思考的时候,比如这个项目要保证上线不出问题需要多少人力、怎么协调资源、采用什么样的技术、会出现哪些问题以及应该分配多少资源应对等等

    关于创业,我个人认为在这个时间给出这个建议是把你往火坑推了,先去市场看看自己能拉到多少投资,然后再看看这个业创不创的起来

  • 你说的是热部署了吧,我记得这方面的资料还挺多的啊

  • 该不该离职了? at May 15, 2019

    感觉哈,无论你下一步打算辞还是不辞,先和你的领导好好聊聊,你为什么想走,你在意的点在哪里,你对下家的期望,发牢骚就行,但是注意找个没人的场合,你的领导既然过问你请假了,证明人家并不是完全不关注你,好好说明一下,不然很多有责任心的人会压力很大,觉得自己的领导风格甚至为人是不是有问题。

    该走不该走这个问题,问你自己就行,如果是薪资问题我建议选择走,因为这个问题在多数情况都是不可调和的,即便给你涨了,你在同事和领导这里都很难和之前一样的信任关系,这么一个工作环境没多久你还是会想走的。

    家庭问题啊、生活问题啊这些也属于不可调和的矛盾,建议准备走吧。

    如果是其他问题的话,我建议你至少留半年到十月再打算了,比如上面说的,不规范问题,这个不是你换地方能解决的。全行业多数公司都这样,主要原因还是职业歧视,开发门槛比测试高,经理以上级别晋升环境又比测试好,开发有进度压力的时候,凭什么听你的,这个情况只要你还是测试,多数情况无解。只能找你的领导商量,解决不了至少把苦水吐出来。

    真心觉得忍不了,先报个班静下心不管是开发技能还是产品技能,学完看看内部转岗的机会再走,不然你的简历投开发或产品都没人看。

  • 首先建议和产品沟通,根据业务的重要性把用例的优先级划分出来,把最关键的I/O点做自动化覆盖,放到持续集成去

    然后根据开发的技术方案逐层往下覆盖,其中关键的业务方法和工具类要求开发必须有单元测试保障

    上述的事情记得要整理出文档,给出定性和定量的指标,比如:

    1. 资损表
    2. 与开发确认的需要覆盖的路径、在设计文档有没有体现、对应模块责任人是谁
    3. 定期汇报覆盖率和单元测试覆盖场景抽查的结果
    4. 重构的改动量和需求改动量的比较

    以上,如果不能直接汇报给老板,最起码要汇报给HR或者和绩效相关的部门
    如果遇到技术上层管理不执行的情况,至少会有人帮你推动