量化亏钱

只有一条

啥东西

还能咋地 自己卷起来，卷到那个技术部门受不了，你就能去这个技术部门了，你想要业务精通，你就继续钻你的业务

技术最大话事权的都这么不靠谱了，不是工资很有吸引力的话，建议赶紧跑

越来越好

稳重向好

个人观点

1. 这样做，只是为了方便管理，但是效率性，可能达不到理想状态
2. 业务部门自己开发测试工具，开发之后，会更符合业务需求，并且需求沟通，会比较顺利
3. 统一提交到技术部，可能会存在需求沟通障碍，毕竟，技术部，也不懂业务，只懂开发
4. 就好比，把家里的早餐，中餐，晚餐，全部外包出去，做成什么样，全凭外包良心，哈哈，谁也给你加了什么，谁也不知道会做什么菜色给你

模拟一时爽，实操火葬场。敢问大哥有几个底裤可赔

解不解决问题不知道，反正应该能解决一大堆制造问题的人

敏捷要依靠比较高的开发质量，不然的的确会出现这种问题！一是被测系统复杂度过高，牵一发而动全身，测试覆盖率的跟不上。第二开发质量跟不上，改一个问题，引出多个问题。敏捷要用有限的资源做到刚好的测试，那的确会存在上述的问题

说的质量问题,不只是测试的问题

产品要负责需求的质量
开发要负责提测的质量
测试要负责交付的质量

只有各司其职,每个环节都共同努力,这个迭代才是个合格的迭代

简化制度吧，看看哪些是意义不大又耗时的，可以去掉或者其他优化

这个大跨步了 这种容易出现多做多措的现象吧

慢下来

每天花半天写任务，花半天写评估，留一个小时测试，这公司挺好

分析的很好，受教了

把 BUG 和绩效关联，绩效和工资关联。立马解决问题。

是的 现在就是感觉开始已稳为主了，但是就产品来说，大多数补丁其实客户是感知不到的，所以就还好

感觉你这 3 张表是给不同的领导看的，一个是你的测试直属领导，他可能是要汇报到总监那边（也可能只是想了解你的工作安排）。另外一张是项目经理看的，他要统筹开发和测试的进度（其实也是为了汇报工作）。第三张感觉是给开发 leader 看的，他应该也是有上级要汇报的。这个看上去不像是管理不善，而且似乎还能从每天及时更新中找出潜在的风险点。

真正有问题的管理模式是，什么都不需要写，然后还一问三不知的领导。有问题就甩锅到下面，也不问下属当时发生了什么，然后等下属知道的时候，分已经扣了。

这种看 leader 风格吧。

我们也会需要写日报，日报主要是给团队 leader 看的，方便 leader 了解每个人工作进展情况。

妙啊

是的，你分析的很到位，不过，我们都是用维格表这个平台。

现在公司普遍都是需要写日报吗？我觉得很虚，每次写日报，总想往里面填点东西，虽然不真实，也无法反应实际的工作情况

"老板喜欢看敏捷，那就在测试报告上面再用文字润色一下，把功劳归因于团队向敏捷靠拢即可",妙啊！

加强对测试用例的评审环节吧。没有 prd，不拉产品和开发一起评审测试用例，肯定会有很多理解不一致的地方。