9-16

小公司测试，就一背锅的

可是一旦搞坏身体，可没有老板会去制造药物医治，最多换只帕鲁。我是觉得好死不如赖活，没必要太拼命，一旦搞出慢性病，亏死了。应该基本互联网工作的都有腰肌劳损啥的，部分透支身体的，中年后就知道代价了

9-18

9~19

咋整

除了结论以外勉强能接受。
结论应该是：
你不干，有的是帕鲁干。
--穷才是最大的病。

别的不知道，至少我在的部门目前测试的话语权在进一步丢失，决策团队没一个懂测试的。

不要一下开太多，开多了有限流，就会 500

原来如此，我一直以为是有专门的企业在管理

5-18

啥叫左移，啥叫右移？自动化才叫左移右移？点工维护好用例做好用例评审积极推动技术评审，上线后做好线上验收做好监控告警，有啥技术难度吗，还是这些不算左移右移？只有做质量的测试和点工的区别，不存在测开和点工的区别，没有做好质量想法的测开和点工也没区别

8-18 ，我自己前后再调休一天，7 号回家，20 上班

网站是用爱发电，将就看吧，社区管理员也都是企业的一线工程师，年底搞绩效都忙得很。

其实测开更容易被替代，本身做的也不是项目本身，离开了能有啥影响？ 不管你是电工还是测开，关键还是得和核心利益业务有绑定作用，就算是点工，如果当前公司主要盈利的项目你是主测，我相信绝对没领导那么傻把你开了。再比如你是技术比肩开发的测开，非利益核心业务的，你再厉害也是优先被干掉，毕竟没有你了，业务还是有人测，测试主要工作就是业务测试

点工太容易被替代了，当然甘当点工也是 OK 的 拿钱少，操心的事也少；想拿钱多，当然技术得好，左右移都干得下来，

不要一下子开太多窗口，两三个两三个的看

偶尔挂了也正常，毕竟是用爱发电的社区

新年快乐~

8~17 号

10 号，节前请一天假

18 年做测试，然后看过一些左移右移的概念、测试模型中的 W 模型、《谷歌软件测试之道》
后来我给自己总结：
左移是推上游产品经理，和产品经理正面聊需求文档的细节逻辑。推上游的研发，给研发提供自测用例，帮研发挡一些工作，发版前和研发聊实现细节
右移是多写傻瓜式文档给生产，多收集生产提出的需求闭环给产品经理，让产品越来越简单
提升技术不在我自己的左移右移概念里面，属于个人为了偷懒要做的工作
按这个思路，后面版本质量也提升了，同事也相信我的能力。相对的我执行测试还变少了，偷懒偷的光明正大
以上是因为我也信任另外一句话，需求设计阶段的修复代价是 1，到用户手里在修复的代价是 100

大年初一，请了两天假

年后 hr 啥时上班，等着投简历呢

6 号放假