只有一条

啥东西

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

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

越来越好

稳重向好

个人观点

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

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

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

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

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

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

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

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

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

慢下来

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

分析的很好，受教了

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

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

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

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

这种看 leader 风格吧。

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

妙啊

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

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

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

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

带上线多少 bug 是测试没发现还是发现了开发没有资源和能力修复？如果是前者，说白了就是测试进了项目组心有不服、对抗决策、敷衍工作吧；如果是后者，单独成立一个测试团队就能解决？还不是交付说了算？
天下大势，分久必合，合久必分！测试放在哪里从来都不应该成为质量差的借口，只不过会给开发负责人如何掩饰自己团队的代码质量差带来不同的难度，素来就是——测试向谁汇报，谁承担责任