挺不错的，类似自检的 wiki

被你攻陷了了

你该不会是美的那边的吧？ 玩这么多花活？

有一项就为 C 能推下去吗，按你这 6 项，我们提测的基本一个也达不到

好几处标准比较模糊，只能凭主观下结论。话说这会不会加剧研发和测试的对立？

在质量意识上也是进步，不过是把项目管理矛盾转嫁到测试身上，理论应该研发团队跟踪比较好。

这种就是管理者搞 N 斗的扯蛋，把矛盾转嫁到开发和测试之间，也不太懂条例里居然忽略了矛盾源头的产品组。一板一眼的条例去定论复杂现实的工作情况，最后都是成为裁员或者整人的利器

测试给开发打分，还跟绩效挂钩。。。这是什么脑袋想出来的主意

只能说，按照我们小公司，6 项，几乎为 C，但是现实情况就是如此，项目压缩开发的时间，开发压缩单元测的时间，以及理解需求的时间，需求变化快。

没这个必要，给一个冒烟测试清单让他们自测通过后再提测就好了（前提是排期给出开发执行冒烟测试的时间）

提高提测质量应该着手在单元测试、CI/CD、自动化冒烟等手段，以开发自测作为门禁，而不是搞这些政治意味大于实际产出的烂活

实践是检验真理的唯一标准，过一段时间，你再来摆摆

期待后续分享

统一回复一下：

1.冒烟测试是有的，但是依然出现了提测质量低、设计文档缺失、提测信息缺失的情况，导致测试工作难开展。
2.打分是匿名的，只有研发 leader 可以看，且不会占研发绩效大的比重，只是提供给研发 leader 参考，作为研发 leader 的辅助打分数据。
3.现阶段是刚开始试行 1 个季度。

我这边也开始对开发提测质量进行评分了，只是给开发提供自测用例 ，还有其他把控方案吗

看了这个标题时候的感受：
问题是： 研发提测质量导致测试工作量加大，因此公司内部开始推行测试对研发的提测质量打分，与研发的绩效考核相关。
对策是： 给研发提测质量进行打分， 请问这不会加大测试工作吗？ 难道研发提测质量的提高只要政策一出就能马上改好吗？在没有改好之前，测试工作量是大了还是少了？

看了 测试对开发质量标准的感受：

1. 研发文档，具体指什么？这个有过于教条的问题，也很难评估，写一句话说清楚了和写一大堆说不清楚，不是有产品经理有需求文档吗？不是有 Bug 描述吗？不知道这个指的是什么。
2. 测试顺利程度？这是什么意思？主流程没有 Block 的 Bug？低级 Bug 不低级根本不重要，只有严重程度高的 Bug 才重要，所以低级 Bug 是什么？
3. Release Notes 需要完整准确： 我有点好奇，难道没有 Bug 管理系统吗？修改了 Bug，直接 Bug 就进入 Release Notes 呀
4. 是否有自测： 不是和测试顺利程度有相关性吗，测试关系的是结果，是不是否自测已经是手段了，如果质量好，不自测由怎么样？因为人家找到办法了，你管不着的，看结果的。这和表示质量的指标没有一毛钱关系
5. 是否有已知问题： 就算知道了，也不告诉你，你知道吗？也不是质量的指标吧
6. 变改变测： 这不是常态吗？有 Bug 马上修改，和方便就发布了，马上验证，否则 CI 要来做什么？我很难理解这个的出发点是什么？变改变测很明显好处是开发测试流程缩短了，不太好的是，确实有时可能会改错，或者影响一下其他，但是我觉得没有上集成环境/回归环境，变改变测是常态呀，要不然发明哪些 CI 我不知道为了什么？

当然一笑而过，只求大家都不要太为难相互，出问题之后可能有很多原因的，太宽泛的提测质量不好一句话很难说清楚，没有具体的东西的话，之后怎么评估提测质量好了呢？工作不要搞得像仇家一样。

提测时检查相应的文档是否给出，自测的用例结果是否存在。如果有问题直接打回，如果没问题测试继续执行自测用例，P0 用例如果有失败先确认，确认执行失败则打回。
另外，绩效中提高打回的扣分。