可以没有测试工程师，但是不能没有测试这个动作；白盒也好黑盒也罢，质量是需要付出代价的，质量和成本效率本来就是矛盾的。多被甲方扣几次钱就老实了

1、如果公司领导不知道现状，应该整理并有理有据的向上暴露问题，给出你的解决方案建议；有问题才有机会
2、如果公司领导知道现状，且对产品质量没有高要求，那该打折打折；提前对齐要求
3、如果对产品质量要求高且，但没有下决心要投入成本去做改变；那么走

单一指标不具备参考价值，结合漏出率、产品模块 NPS 等指标效果更佳

端到端的测试成本（包括场景用例梳理、多团队甚至多公司协同）非常的高；在端到端测试之前，非常有必要约定各系统各板块对于集成接口的质量保障策略：
1、各系统集成接口要做充分测试，保障提供接口的健壮性及正确性（确保别人调我不出错）
2、所有场景数据往下游流转的通畅性，因为你的下游接口提供者不清楚上游会有多少场景（确保我调别人不出错）

管好自己、做好咬合约定，能够让端到端测试成本和效率有大幅改善

自驱是反人性的，它的定义是自己给自己定目标，自主行动去达成目标；所以通过外力被动的来牵引，无法达成自驱力的激发。
树立榜样和标杆，适当的放大自驱力强的同事在团队的影响力（晋升：物质激励影响；在团队点名表扬：精神激励影响）；人性是期望被认可、被表扬的，潜移默化的影响其他同事的心智：用人性去影响人性

一个宽表，收纳所有的源数据（T+1 job 每日更新），比如：bug 每个级别的个数（按人维度去落）；
另一个积分表，按源数据计算得分每一项的分数；表怎么设计也关乎你想怎么呈现，仅供参考

之前用 jacoco 二开做的染色，也集成在测试平台上了；暂时没重视这块，也没去做更深的改造

有的，产研的质量看板早就做了的，只是没有按天梯的模式来做；
公司建设的能效指标有很多都是测试平台沉淀下来的数据提供出来的，比如：bug 响应速度、千行 bug 率等等
质量看板维度也分了：项目质量看板、团队质量看板、个人质量看板

我是测试，也是产品也是开发 前端是我们组其他小伙伴做的，集成在我们自己做的测试平台上。这个东西从产品设计开发上线也就用了两三天吧，花时间的是前面的构想、指标收集对齐。不存在项目一说吧，就是一个想法把它实现了而已

哈哈，感谢夸奖，确实在整个构思到开发落地推行，碰到了来自各方的阻力，让我学到了不少

匿名的这个思路挺好，可以减少同学们日常对榜单的关注

在收集指标的过程中，我们也收到到了大量的指标：接近 50 个，分析过后，能够量化的就比较少，且有些指标属于比较有业务特性、角色特性的，难以去做拉通；所以肯定会出现有很多具体的工作难以被纳入到这套积分体系中，特别是高职级的同学，基础工作往往做的并没有那么多。所以数据量化结果也仅仅是做参考，并不会决定生死；因为工作中除了可定量的结果，还有定性的输出，同样是不可忽视的。

也确实会存在业务性质、复杂度，不同团队不同的开发质量，测试同学个人工作习惯等等的差异性，导致基础数据本身就存在偏差，在参考数据的同时我们也会主观的去判断，当然这部分没办法硬去量化一个系数简单的做加减乘除

要直接通过这个体系去识别谁比谁强，谁比谁产出多，会很难找到答案；但是可以很容易的识别出比较异常的 case（谁在划水）

嗯，对个人绩效和团队想要的结果都是引导作用，不会直接与绩效挂钩，这也是我们建设这套体系的出发点