慢下来

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

分析的很好，受教了

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

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

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

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

这种看 leader 风格吧。

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

妙啊

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

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

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

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

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

看公司怎么调整吧，之后也会把调整的些举措更到这个帖子上，也算记录下质量提升的过程吧

线上这么多问题，产品杂活下来的

会有客户配置和二开的原因，不过也确实多 正是因为这样才从公司层面才会重新去关注这一块，去重建

日报 + 统计表这个可以理解。日报一般对团队老大，进度表一般对项目老大或者更上面的老大

不过进度表要人工写 3 遍，属实工作量有点大了。听起来三个表受众是分开的，任务条对应绩效统计；开发任务表对应项目总进度（原谅我第二个表和第三个表真没搞清楚区别是啥），个人理解核心问题其实不是表太多，而是缺少一个一处数据源可以关联多个报表的项目管理系统。

可以看看禅道或者 tapd，引入一个这样的系统吧，系统可以基于一份数据生成多个表，测试人员写任务条（含进度信息），每个测试阶段一个任务条，然后任务条可以关联开发任务展示在开发表上，也可以单独拿出来当做测试任务内容，甚至可以复制粘贴到日报里作为日报内容，这样就不用写多处了。

这个 bug 数量，光靠测试估计也没法完全搞定。个人想到的一些零碎的想法：

先出成绩：
对线上的 bug 做一轮复盘，看漏到线上核心原因是啥，对应加上线 checklist 和测试用例，加大检查，减少遗漏到用户侧的严重问题；

再理内部：
测试不对开发经理负责，改为对测试经理负责；测试经理和开发经理评级，共同向更上级汇报；
把提测流程重新捡起来，每次提测后的冒烟记录做好登记，定期对做得好的进行奖励，不好的进行复盘分析，结合开发演示等手段，给研发提高交付质量的压力；
需求评审和测试用例评审流程重新捡起来，让这两块重要内容成为团队重要的共识，而不是走过场；
测试团队内部找一些做得不错的，推起来，将其起到榜样作用

长期预防：
提供开发自测用例及一些相应的工具手段，让开发自测阶段完成更多的检测，保障好自身质量。
一些重要且变动较少的场景考虑做成自动化，用工具而不仅仅是人来加强保障

每天写日报（特意搞了个系统做统计），忘记写按次扣钱，每月统计次数。哎。。

1.上层结构考虑的事情，如果屡屡决策错误，问题没有得到审视，重新设计流程和重典整治乱象。那么你只有两条路，要么跑，要么躺。
2.不是决策者，就做好自己的分内事。一个人扛起整个项目跑的不少，但多数人不是主角。
3.形式主义不等于不干实事，既干脏活，也做领导喜闻乐见的表面功夫，在成年人的世界里并不矛盾。
4.敏捷很大部分在于共识，不仅仅是团队的目标一致，沟通无障碍和需求实现的点到为止，活和成品的转化率是个命题。
5.简单地总结以上：实际能保证质量的是测试流程中的复测，单测覆盖，是灰度的冒烟，是需求热更的严谨评审，那就捡起来，都捡起来。老板喜欢看敏捷，那就在测试报告上面再用文字润色一下，把功劳归因于团队向敏捷靠拢即可。
ps：团队需要质量监督，各部门工作质量不可信，交接存在障碍，就不要伪敏捷，测试做保证质量的事，尽量做老板喜欢的事。项目活着，赚钱才是目的。

再讲个笑话，PRD 现在基本没有，除了标准产品的业务流程会有，像报表，低代码平台，类的几乎没有 PRD，都是一句话需求

补充一点，就是其实日常的测试活动中发现的问题也很多，但是发版当天还是会出现很多问题，也分析过，有环境的差异，历史的原因，还有技术债引起的，但是就是无法解决

其实也不招人 就是原来那批人，只是现在又合在一起了

流程确实很混乱

就这个量级的 bug，测试问题太大了。我觉得不光是测试流程，测试人员的能力也要看下

我觉得最核心还是做好功能测试，初始搭建团队时，不用急着招测试开发，就招普通的测试，对着 PRD 把每一个功能仔细测好，就能避免 95% 的 BUG 了
等质量稳定上去了，再扩招专职的测开，做业务提效工具。
当然，测试经理要规范好测试过程中开发与测试的种种规范。