• 测试所有输出的文档规范 at 2023年02月09日

    整洁即可

  • 测试所有输出的文档规范 at 2023年02月08日

    又不是写论文,排版有要求,内容大于格式啊

  • 测试所有输出的文档规范 at 2023年02月08日

    一切根据项目进行修改,文档内容表述清楚,逻辑清晰就可吧

  • 测试所有输出的文档规范 at 2023年02月08日

    适合自己公司的,就是最好的,没有规范。

  • 测试书籍之我见 at 2023年02月07日

    在 test home 搜书看到这个帖子,这个大佬的回复让我学习了。感谢呀

  • 我们是用禅道记录 BUG,如果遇到这种问题他不改,直接是指派到技术负责人/需求负责人/产品负责人,任意一方负责人去处理,如果这三方的负责人都觉得这个问题不用改,OK,缺陷关闭,出了问题上面三位大佬先死。

  • 不及时处理 bug 还有个风险,就是改一定数量的 bug 后会产生新 bug,尤其到后期集中改 bug,时间紧,改出的新 bug 更容易漏掉,还不好区分是一开始就漏测的,还是后来改出来的

  • 是 bug 就要提啊,发现 bug 不提后面锅肯定是你的,提完之后,开发如果也认为是 bug 但不改的话,线上出问题就和你没关系了吧

  • 分析得很详细啊,像是一个管理者的思考💡

  • 测试的 KPI 个人认为大头就两个,基本都不会变:

    1. 有没有线上重大问题
    2. 有没有及时交付工作

    从你的描述来说,这个员工没有大问题,可能就是额外的事情做的不太好,那绩效就是在中间这块。

    其他裁员之类的考虑:

    1. 这个老员工工资大于他的产出吗?
    2. 业务测试就那么简单吗?随便换个人就行?还是其实是你以为的,换个人的成本就不高了?为什么?
    3. 他的业务测试难吗?有替代的人选吗?为什么没有替代的人选?会不会是因为不太容易才知道的人少?
    4. 线上出不出 Bug 不是以自己的想象来定的,是看是不是真出了大 Bug,如果员工出了 Bug 能和团队其他人一起把他圆过去,也是这个员工的能力,不是吗?要不然你给他背锅?都没有大 Bug 了,还不自求多福,要明白常在河边走哪有不湿鞋的;你如果认为他技术能力不行,那么不应该不出 Bug,更大的可能是 Bug 都能自己处理了,那也是需要承认的一个事实。 和团队合作不错,想换人,不是一个好主意,自行找麻烦。

    最后:

    • 个人认为看不起点工的测试不适合当 Leader,你的业务都可以用自动化完成?如果不行,总会要去点击的,那就有点工,都是在为你实现你的绩效,为你实现绩效了,比如说没有出 Bug,就知足吧。你自己去都不一定不出 Bug,不是吗?
    • 所谓的潜力其实也是预测,是不是每一个能兑现潜力呢?如果不是,那么也都是自己的想象中的高潜,并没有得到验证
    • 年龄不是问题,要说问题成本才是,如果成本不高,稳定,说明人期望值也不一定很高,没有太多动的必要,除非你觉得你有更好的选择;替换一个人也有成本的,你如果非要打低绩效,你最好想清楚如果人不高兴真走了,你要方案是什么,如果人走了,换了一个人,效果非常不好,你要怎么办?
  • 17 楼说的很好,公事公办就行。除非前端最后能甩出去说,这个不是 bug。。。找 bug 报 bug 是我们测试的事情,后面的事就是开发的事情了。其次在这种情况下,测试不应该认同自己要被挨批的观点。测试不是保姆的,和开发之间是平等的。

  • 一般公司的 KPI 往往都是做好本职工作的同时,思考现有工作中的不足,实现所谓的降本增效的改进,就测试而言,往往就意味着写自动化,搭平台啥的,因为单就业务测试点点点,体现不出什么产出来,线上不出 bug 则已,出了 bug 就是锅,年底考核时大家都做的差不多,作为领导者也不好说给谁好绩效给谁差绩效,那就只能看这些工作以外的事情了呗,比如加班时长……等等

  • 想问下大家,对域名是怎么去测的

  • 漏测和开发漏实现功能是一样的。用例一定需要评审,还有就是需求一定要理解透彻

  • 核心要素:

    1. 自己人 2.听话 3.便宜 对于中层的管理者来说,一个年纪大的不听话的真的是一言难尽。有的选为啥不选个年轻的嫡系便宜又好用? 什么养家糊口,什么身体不好,这是都是打工人从自身考虑问题,工作最根本的属性还是交换。

    然后再从老板来看,除非体量大到不太能出事故,否则的话,客户关系好,事故也就是一顿酒解决的问题。为什么要养几个看上去没啥产出的人?钱多烧的慌?

    不能卷的最好的策略就是认怂,苟着。

  • 测试的本质工作就是 做好业务测试,线上没有问题。只要他没摸鱼,那就是没有问题,什么技术提升的都是花架子,技术再好线上各种问题也没有用

  • 我个人感觉哈,点点点做得好,25 岁可能也可以达到这个程度。
    而且我还有点疑问,功能测试十几年,真的会一点技术都不懂么,在接技术需求的时候多少还是会接触一些技术相关的东西吧?
    另外整体看来 “给布置的 kpi 技术提升目标始终完不成” 我感觉这个是比较明显的一个问题(我个人认为这个是问题),会影响到团队的绩效。如果这点没办法优化的话,建议还是换个环境,双方都会更舒服。

  • 我感觉这个问题有必要拆分一下公司的情况,不同规模不同阶段的公司,对于这样的一个员工可能会有不同的看待方式:
    1.稳定成熟的业务,大厂/国企/央企的部门,比较稳定的情况;
    2.开拓创新多变的业务,互联网公司,中小微企业,需要一个人独当一面的情况;
    3.相对稳定的外包业务,如车企/外企的外派岗位;

  • 哪托有句经典台词:“我命由我不由天”,你的打工命由你不由管理者。政治术语叫:发挥个人的主观能动性。

  • 裁掉一个 35 的业务测试 , 还是一个线上不会出问题的那种, 不是领导不行就是公司不行,眼界太低

  • 你也有 35 岁的时候。。

  • 我觉得这个帖子很有意义。因为大家都会有 35+ 的一天,但不是所有人都能成为决定他人命运的领导者,所以采访一下身为管理者的真实想法,作为参考很有必要。究竟是卷还是躺,跟什么样的领导干活去什么样的公司,希望这个帖子能多多地讨论。

  • 测试唉,基本没有线上事故,这还不称职?换个技术好的,搞几个线上事故?技术能带来多少效率提升?线上没事故这才是真本事

  • 如果都是产品发现的,说明这些都是产品文档上列出的:这种漏洞一般不太应该。
    建议理解产品文档时,将各个规则、细则通过思维导图等等一一标记出来,测试时一一核对。
    当然态度决定一切,以后继续努力

  • 你跟前端开发联合,跟领导层反馈,前端人手不够,得加人。