讲个笑话，先讲背景，公司是一个 ToB 类型的企业，去年一直在推行敏捷，为此还专门请了培训老师，然后老师来的第一件事就是部门拆分，于是测试就分在各个组里做，各自工作不重复，没有冒烟，少量单侧，因为没有比较强力的推进评审，用例也就是简单看看，各个测试仅对各组开发负责人负责，然后轰轰烈烈一年过去了，现在老板觉得产品质量太差，简单讲个数据，一月两次发版，每次的发版 bug 都在百个左右，每月线上 bug 也在百左右（当然这个数据也有部分配置和二开原因），于是乎又专门请了一个测试经理来重建测试部，目前工作模式还没有变化，但是不知道之后会有什么变化，现在测试经理也在收集下面人的想法，你觉得有什么好的方式可以改变现在这个困境呢
自顶
说明测试流程，还是有严重的缺陷
如果发布到线上，还有这么多 bug，肯定是测试流程出了问题
测试负责人要担责
我觉得最核心还是做好功能测试，初始搭建团队时，不用急着招测试开发，就招普通的测试，对着 PRD 把每一个功能仔细测好，就能避免 95% 的 BUG 了
等质量稳定上去了，再扩招专职的测开，做业务提效工具。
当然，测试经理要规范好测试过程中开发与测试的种种规范。
就这个量级的 bug，测试问题太大了。我觉得不光是测试流程，测试人员的能力也要看下
补充一点，就是其实日常的测试活动中发现的问题也很多，但是发版当天还是会出现很多问题，也分析过，有环境的差异，历史的原因，还有技术债引起的，但是就是无法解决
1.上层结构考虑的事情，如果屡屡决策错误，问题没有得到审视，重新设计流程和重典整治乱象。那么你只有两条路，要么跑，要么躺。
2.不是决策者，就做好自己的分内事。一个人扛起整个项目跑的不少，但多数人不是主角。
3.形式主义不等于不干实事，既干脏活，也做领导喜闻乐见的表面功夫，在成年人的世界里并不矛盾。
4.敏捷很大部分在于共识，不仅仅是团队的目标一致，沟通无障碍和需求实现的点到为止，活和成品的转化率是个命题。
5.简单地总结以上：实际能保证质量的是测试流程中的复测，单测覆盖，是灰度的冒烟，是需求热更的严谨评审，那就捡起来，都捡起来。老板喜欢看敏捷，那就在测试报告上面再用文字润色一下，把功劳归因于团队向敏捷靠拢即可。
ps：团队需要质量监督，各部门工作质量不可信，交接存在障碍，就不要伪敏捷，测试做保证质量的事，尽量做老板喜欢的事。项目活着，赚钱才是目的。
这个 bug 数量，光靠测试估计也没法完全搞定。个人想到的一些零碎的想法：
先出成绩：
对线上的 bug 做一轮复盘，看漏到线上核心原因是啥，对应加上线 checklist 和测试用例，加大检查，减少遗漏到用户侧的严重问题；
再理内部：
测试不对开发经理负责，改为对测试经理负责；测试经理和开发经理评级，共同向更上级汇报；
把提测流程重新捡起来，每次提测后的冒烟记录做好登记，定期对做得好的进行奖励，不好的进行复盘分析，结合开发演示等手段，给研发提高交付质量的压力；
需求评审和测试用例评审流程重新捡起来，让这两块重要内容成为团队重要的共识，而不是走过场；
测试团队内部找一些做得不错的，推起来，将其起到榜样作用
长期预防：
提供开发自测用例及一些相应的工具手段，让开发自测阶段完成更多的检测，保障好自身质量。
一些重要且变动较少的场景考虑做成自动化，用工具而不仅仅是人来加强保障
100 个线上 bug。。。难以想象~~~
线上这么多问题，产品杂活下来的
带上线多少 bug 是测试没发现还是发现了开发没有资源和能力修复？如果是前者，说白了就是测试进了项目组心有不服、对抗决策、敷衍工作吧；如果是后者，单独成立一个测试团队就能解决？还不是交付说了算？
天下大势，分久必合，合久必分！测试放在哪里从来都不应该成为质量差的借口，只不过会给开发负责人如何掩饰自己团队的代码质量差带来不同的难度，素来就是——测试向谁汇报，谁承担责任
加强对测试用例的评审环节吧。没有 prd，不拉产品和开发一起评审测试用例，肯定会有很多理解不一致的地方。
感觉老板喜欢推敏捷， 其实还是想迭代速度快一点吧， 不想搞几个需求就拖那么长时间， 毕竟市场如战场。 其实老板心里也知道在这个阶段质量不是那么重要，别有严重的 bug 或者 bug 别太多就行，还是抢市场更优先。 哪天老板开始抓质量了，那就说明要么是之前有点玩脱了，质量有点看不下去了。 要么就是客户的数量已经到一定程度了， 必须要开始抓质量来稳用户了。 要不然以 TOB 产品的特点，质量不好的话光是给各个版本打补丁都会被玩死的。
把 BUG 和绩效关联，绩效和工资关联。立马解决问题。
慢下来
说的质量问题,不只是测试的问题
产品要负责需求的质量
开发要负责提测的质量
测试要负责交付的质量
只有各司其职,每个环节都共同努力,这个迭代才是个合格的迭代
敏捷要依靠比较高的开发质量，不然的的确会出现这种问题！一是被测系统复杂度过高，牵一发而动全身，测试覆盖率的跟不上。第二开发质量跟不上，改一个问题，引出多个问题。敏捷要用有限的资源做到刚好的测试，那的确会存在上述的问题
下面人的想法有什么用？
核心是数据分析，而且是客观的数据分析。
各种类型的问题比例，然后再来分析是内部沟通问题，还是项目排期，甚至可以是个别人的问题。
测试经理能改变的只有流程，是无法改变真正执行过程中遇到的问题。
简单就事论事就好，至于什么重建测试团队，这只是一种执行策略，能不能真正改善，早着呢。
很多公司，仅对敏捷开发流程中 “变更快”，“迭代快” 了解，往往忽视敏捷开发需要靠自动化测试辅助和流程管控；
实际项目过程中：
产品经理：需求写的简单，能用一句话概括，就用一句话；
开发工程师：需求评审听着迷迷糊糊，大概知道相关功能，但是开发是否能实现，还需要看开发时间和技术，到了提交测试时，缺乏自测和对业务了解，开发仅看需求中一句话内容，低级问题频繁出现；每提交一个问题，恨不得给测试提供一个版本测试，偶尔一天提供两个版本；
测试工程师：由于需求变更快，往往不会编写测试用例，可能会写功能测试逻辑图，拿到测试版本，提交个上百个问题，还担心遗留问题，反反复复回归测试，想避免修复 BUG 或者合并代码时，之前功能旧功能产生问题。
理想中敏捷开发：
产品经理：会将需求内容，分解到每一个详细的任务（WBS），让开发明确需求；
开发工程师：根据实际需求，了解其中的业务需求和标准，进行开发；提交代码到代码库时，会有开发工程师走读代码，合并到代码库时，会自动触发代码质量检测工具或者代码覆盖率检测工具，检测代码质量；以上没问题时，再提供测试版本给到测试，并提供代码修改记录；
测试工程师：拿到测试版本，先跑自动化测试，比如 UI 自动化测试，接口自动化测试等，同时进行业务功能测试；提交问题点到开发工程师环节修改；如果测试完成后，发布测试报告；软件版本发布到上线后，再次在正式服进行重要功能回归测试。
哦，什么也没有做，就是哪块有问题哪块就堆人，不加人只加工作量
