个人还是很喜欢测试的，质量的把控于我而言有种可以去掌控和运筹帷幄的感觉。
快乐的时候：
1.发现未经测试发布的线上问题，挽回大量损失，被主管和同事认可的时候
2.提出了产品和开发都未曾想到的重要测试点并因此发现问题的时候
3.自己主导一个项目的全部测试并最终顺利上线，获取用户一致好评得到奖金的时候

只要你表述清楚，bug 涉及的所有条件和步骤及具体表现都有就行，主要是让开发可以快速复现，让产品可以快速了解。如果要严格点，最好是在 jira 上对于步骤和描述给个具体的模板，按模板来会更标准一些，也便于归档和查询

后面我才知道是急着休产假，不想费劲儿去输出了

如果是标准流程，当然不能接受。但现实是看老板对于这个产品的期待程度。如果是希望有一个较高的质量，那肯定是打回，如果是产品认为这玩意儿可以先上线，交代任务，再慢慢来改，那就要靠商量了。毕竟不是每个公司都是大公司，都是标准流程。很多时候做为测试，你如果执意要按标准来，会让大家难堪，只要沟通的东西有记录，出事不怕背锅就行，剩下就看你怎么灵活处理了，你要给出测试不通过的结论，但产品上不上线就不是你决定的了

我遇到过产品需求模糊，开发改了几版才对齐需求的，真就是各理解各的，一点沟通没有。我在中间沟通，每次产品都是挤牙膏输出，测完又说这里没按照他要求来，真是离谱到家了

大多数公司的领导对于 AI 没有清楚的认知，即想要低投入又想要高回报，吹得太过了。导致下面的人不得不面向绩效编程。现在我们公司用 AI 最有用的就是开发自己用 AI 辅助编程，老板提的什么用 AI 重构代码，优化提升效率，在本来审代码就不严格的公司感觉就是天方夜谭，所以用来用去还是在屎堆上缝缝补补。太多小公司老板觉得一个 Cursor 啥的就能帮他省很多钱

接近年底的时候辞吗？年终奖不要了？而且这个时间大概率是不怎么招人的，不太建议这个点裸辞

管理都是向上管理，不做好 ppt，怎么加钱呐。这种东西除非从上往下推，领导层真心想做才能做好，不然都是绩效指标

没啥好办法，时间给够硬着头皮做。建议不要用 AI，东西少无所谓。东西多了，还是自己搭框架比较好，便于后期维护。AI 只适合在屎堆上缝缝补补

所有页面做 UI 自动化？除非你们做一次性的 这后期元素变更啥的，维护成本得多高