效能度量 测试的产出到底是什么
社区经常会讨论，组织部门和效能的问题，但是如果你作为一位管理者，或者是其他部门的人，你觉的测试的产出到底是什么？
质量保证，或者产品优质，这些都只是结果，且单纯靠测试是肯定不行的，但是在日常的工作中，测试的产出到底是什么？
可能大部分场景来说测试有独立部分比较合适，但是本人亲身经历：测试老大平时没有什么卵用，只抓故障数和效能，不顾你业务多忙一味只要效能产出，搞得好像业务测试不花时间似的，也不会多给你资源，以便完成他的 OKR。对于这种测试领导，反而是个累赘，不如干掉的好。有这种测试管理者的存在只会让测试在业务的专注度分心，反而影响业务质量。坦白讲，如果我是公司的创始人，我会把测试部门干掉，把这些测试管理者干掉。
分业务体量而言，业务不同的发展阶段，本身在产品质量上的目标是不一样的。
- 业务起步阶段，就是要快，要争取时间窗口，产品质量不可能是业务的核心。整个产品根本就不复杂，对测试的要求也很明确 —— 发现 Bug，线下抓一个 Bug 线上就少一个问题。本质上问题处于有限阶段，问题是可以被修复完的。
- 业务发展阶段，业务长期方向明确，大家持续为业务添砖加瓦使得业务已经呈现一定复杂度，线上问题反馈在研发内部已经开始难以消化，产品质量开始成为大家的关注点。随着研发团队膨胀质量甚至出现回退，很容易就发现 50 人的团队使用 5 人的合作方式已经不可靠了，由于流程紊乱和信息不对齐，非常多低级 Bug 在研发早期被引入，这时测试的产出除了单纯抓 Bug 外，引入了更高的要求 —— 规范出更好的研发测试流程，在不同阶段定要求定标准，最终把控产品线上质量风险；Bug 是解不完的也测不全的，那如何兜底线上质量问题、如何高效吞吐需求、如何低成本跟进线上反馈，也就出现了效能建设的要求。
- 业务成熟阶段，业务整体形态已经稳定，业务增长出现瓶颈，产品研发都在探索以求进一步突破用户体量。一般到了这个阶段，研发内部甚至都有人力空余下来，去做横向通用的技术建设（大公司就搞中台），本质目标是希望从成熟业务中孵化出通用能力，让下一个新兴产品做得更好更快更低成本。这种情况下，测试和研发可能是竞对又合作的关系，因为大家都在关注技术和质量，大家都可以做类似的建设。测试的产出要求就更加多，点点点的测试就很明显外包化了 —— 通用的质量效能建设，要求产出可支持横向拓展的平台服务、工具流程、质量标准，抽象来说，就是需要成熟业务的测试团队去产出 “可复制的质量”，从而让每一个产品都能享受到比较好的质量建设。
以上其实并不全面，在细节上千丝万缕，不同的团队配置，不同的业务体量，不同的公司基建都会有不一样的要求。
质量保证
说的也有道理我很同意观点，但是另一方面觉得可能是，人不在于多而在于精。目前公司一个项目对接一个测试，项目比较大对接两个测试全是外包同学，基本开发中做单元测试，开发完做集成测试，上完线回归测试，跟踪线上问题，上线后等待二期需求的更新，过程中过渡的忙一阵子，上线后基本没有事情忙了，总的来说是质量保证没错 但是要将就正确的方法
测试属于研发体系，当然评价也要从研发体系侧评价测试的产出，测试就是保证产品交付质量！当然这个也可以由研发自己完成，有没有测试要看老板平衡和权宜，我只是个打工仔，老板请我我就干！
说的真好，所以我离职了！
很难被衡量，但不能代表完全不需要，所有的东西都是这样，没出现意外就觉得是理所应当，一旦出现事故，就觉得要是当初怎么的怎么的就好了。。。
把测试部门干掉之后又怎么样呢？ 功能就不用测，直接上线了吗？
最后还不是要有人出来做测试的工作（比如开发，比如产品）？
不要把你碰到觉得不好的测试管理者看成整个行业的统一现象。
为什么会有开发，测试，测试开发的职位就能说明一切了，不要用开发的思维来衡量测试。 开发的思维是绝对无法替代测试思维的；同理测试的思维也绝对不可能代替开发思维
交付可用的产品，做好产品发布的最后一关。
但本质上来说还是辅助角色，产品的核心价值是由其他人提供的。
分业务体量而言，业务不同的发展阶段，本身在产品质量上的目标是不一样的。
- 业务起步阶段，就是要快，要争取时间窗口，产品质量不可能是业务的核心。整个产品根本就不复杂，对测试的要求也很明确 —— 发现 Bug，线下抓一个 Bug 线上就少一个问题。本质上问题处于有限阶段，问题是可以被修复完的。
- 业务发展阶段，业务长期方向明确，大家持续为业务添砖加瓦使得业务已经呈现一定复杂度，线上问题反馈在研发内部已经开始难以消化，产品质量开始成为大家的关注点。随着研发团队膨胀质量甚至出现回退，很容易就发现 50 人的团队使用 5 人的合作方式已经不可靠了，由于流程紊乱和信息不对齐，非常多低级 Bug 在研发早期被引入，这时测试的产出除了单纯抓 Bug 外，引入了更高的要求 —— 规范出更好的研发测试流程，在不同阶段定要求定标准，最终把控产品线上质量风险；Bug 是解不完的也测不全的，那如何兜底线上质量问题、如何高效吞吐需求、如何低成本跟进线上反馈，也就出现了效能建设的要求。
- 业务成熟阶段，业务整体形态已经稳定，业务增长出现瓶颈，产品研发都在探索以求进一步突破用户体量。一般到了这个阶段，研发内部甚至都有人力空余下来，去做横向通用的技术建设（大公司就搞中台），本质目标是希望从成熟业务中孵化出通用能力，让下一个新兴产品做得更好更快更低成本。这种情况下，测试和研发可能是竞对又合作的关系，因为大家都在关注技术和质量，大家都可以做类似的建设。测试的产出要求就更加多，点点点的测试就很明显外包化了 —— 通用的质量效能建设，要求产出可支持横向拓展的平台服务、工具流程、质量标准，抽象来说，就是需要成熟业务的测试团队去产出 “可复制的质量”，从而让每一个产品都能享受到比较好的质量建设。
以上其实并不全面，在细节上千丝万缕，不同的团队配置，不同的业务体量，不同的公司基建都会有不一样的要求。
说下自己的理解，对于测试这份工作而言，我们的产出有几下内容：
一个思维：就是你的测试思维，针对每个版本或者迭代，结合自己的经验和能力，设计出高效的测试用例，体现你测试的专业性，而不是别人眼中的 “点点点”。
一份报告：一份合格的测试报告，说明测试范围及并给出测试结论，如果有风险，应提出自己的风险和意见，让团队共同意识到风险，并共同寻求解决方案。
一点责任：做为测试人，经过自己测试过的内容，应该承当一份责任，能够保证产品的基本质量。如果线上出现问题，应该有责任和能力去解决并加以改进，不能把问题都归结为团队质量意识不强。
4.体现专业：你应该让团队意识到，测试，你是专业的，你拥有测试思维，能够通过自动化或者其它手段解决测试过程中遇到的测试问题，能够推动团队逐渐形成质量意识。
至于测试团队规模，13 楼已经说的很多啦，可以参考。至于题主提到的 “如果我是公司的创始人，我会把测试部门干掉，把这些测试管理者干掉。” 我只能说，庆幸你不是创始人。
测试的本职工作是产出产品的信心，而不是 OKR。
有些监工式管理者（自己不干活，天天催你干挑毛病的 SB）为了 PPT 好看，真是啥东西都往 OKR 去写，也不管适不适用，合不合理。做的人又不是他，他管你死活呢。
这是管理者的问题。
领导很重要~特别是在测试行业，测试领导更重要~
