• 喜欢这种内容的帖子😎

  • 最近在给组内招人,我面试的时候主要从以下几点去评估:
    1.对测试流程的理解
    2.linux 实操能力
    3.数据库能力
    4.自动化/性能的能力
    5.对加班的态度 。
    在面试过程中从这 5 个方面针对面试者的简历内容进行详细展开,毕竟每个人的项目经历是不一样的,我更希望看到面试者最突出的点。并在此过程中看沟通是否顺畅来判断他的逻辑能力和沟通能力(虽然此项面试的时候不做为考察标准,但是最终 PK 的时候会综合考虑)。
    之所以这么来做,是因为根据团队目前的状态,我们更希望能找到有经验的,对测试环境搭建,数据库,自动化/性能测试都有一定经验的人,可以快速上手展开测试而不需要从头培养。加班态度主要看接受度吧,因为目前的项目处于初期阶段,需要根据项目进展有一定的加班情况,但是暂时还没有到 996 的地步。

  • 如何评估测试工时? at 2024年06月20日

    没有统一标准,只能说凭借测试组内成员的平均数据为基准。

  • 越迷信技巧越容易失败 at 2024年06月03日

    实际工作中肯定都是基于业务展开的,自动化或者性能的落地都必须与业务强关联。举个例子:前司的自动化测试一开始是一个单独的部门做,是与测试执行团队独立的,结果开发出来的自动化测试工具在推广和应用的时候效果并不好,还提出了全员自动化测试的口号,结果由于每个人的 coding 水平参差不齐,手工测试的时间还压缩一部分给自动化了,导致测试进度缓慢且产出低。在实际工作中跨行业(指的是完全无关的行业)跳槽的应该还是少数吧,比如我之前是做金融行业的,可能跳槽的时候会找相关的领域的企业,大概率不会去找一个做交换机的公司,这其实也印证了精业务的重要性。

  • 越迷信技巧越容易失败 at 2024年06月03日

    感同身受。自认为是一个精业务、懂技术、会架构的测试人员,且在项目管理和团队管理方面也有一些经验。但是面试的时候有很多面试官都过多关注自动化知识,性能测试工具的使用,对底层逻辑和测试策略聊之甚少,岂不知工具只是解决问题的手段,深入理解业务和架构,结合有效的测试策略才是精准测试的根本之道。

  • 人在郑州,我的建议是保持现状。

  • 从你的描述来看,需要的是一个 PQA 的角色。

  • 同意三楼四楼的意见。自动化虽然听起来很高级,但是并不适合你们团队的现状且不能解决问题。单就功能测试方面也有很多可做的东西,就比如测试左移,我认为就可以对你的现状有改善,测试更多的参与到需求分析,设计,编码阶段,负责做保障,提前提出不合理的需求和设计,将问题提前解决,这也是一种突破。

  • 首先,你说的这种交叉测试是有必要的,保证组内不止一个人熟悉对应的功能模块。我们的解决方案是:每个产品/模块有一个专门的负责人,这个人会主要测试该产品/模块,但不一定在每个版本都负责测试该产品/模块,他会参与到该产品/模块新需求评审,负责相应用例的维护,业务流的梳理与面向组内共享培训。相当于给每个模块安了一个唯一责任人,他需要搜集平时该模块的发测版本,每个版本测试中的问题,及时修正补充,根据需要给其他组员定期分享该模块的业务(内容不限,可以是新的功能,新版本增加的用例,问题定位总结等)。测试中遇的问题需要向这个负责人请教,这样也能保证及时了解到版本测试以及漏测情况。

  • 前司有自研的测试管理平台,所有测试计划,任务,用例执行,bug 管理都在上面完成,但是用例必须 excel 导入。大部分人平时喜欢用 xmind 写用例,所以用了 xmind2testcase 工具二次开发,生成可以导入的 excel,用起来还挺不错的。