小公司，公司的转测质量很差，前端页面肉眼可见的问题，还有接口报错，就是随便点点都能发现很多问题。提醒开发自测还是没有多大作用，一个个都说自测了。不知道作为测试的我能给他们提出哪些要求或规范，来提高开发的转测质量，这样我也能高效完成工作。
如果你也有这样的遭遇，快来跟我分享一下你的做法吧！
你们是敏捷还是瀑布呢
测试提供自测用例，明显自测用例可以覆盖但是遗漏到测试环节的 bug，标记为自测型 bug。拿自测型 bug 作为开发提测的绩效考核指标
沫沫sir
回复
敏捷，不过周期挺长，项目分为三个阶段，目前是第二阶段转测，第三阶段还有一大堆功能，所以开发在预估的时间节点就提交了代码转测，着急进行第三阶段。导致一上来就是各种问题
分享给你你敢做吗？
恕我直言，所有间接性的改动都是扯淡，如果你有办法推动这事做未开发绩效考核指标，那你可以尝试，但如果你有这种影响力的话大概率也不会来这里吐槽了。
最简单最直接的方法：怼回去，用你的反问句怼回去，用你的反问句在项目群大群里直接的怼回去，最好找到个急活来反向推动一波：
因为开发转测质量太差且问题修改率较低，导致测试工作大大增加并最终导致无法按时交付
但是！
有些烂泥即使你再怼也糊不上去墙，可是这就不是你的问题了，这个时候你已经很明白的把毒瘤揭开并推给项目负责人啦
记住！
当遇到烂泥的时候，你要么忍着，要么就把他也糊到领导的脸上
今晚打老虎
回复
搞成绩效考核这个我没那个权限，糊领导脸上是可以的
！ 我意思是除了找领导协调这件事，还有什么办法是咱自己能做的，不然去找领导，领导说那你有什么建议，我还是说不上来个 123，给领导提出问题的同时也得有自己的想法建议。毕竟都是为了推进项目进度，高效完成工作，并不是让谁难堪。
开个会议 让开发 show case（演示）下 做个冒烟 全体人员过一下 ，碍于面子 大都会仔细点的
一样的难题
感觉当前节点能推的就是冒烟测试了，可以给他们提供冒烟用例，演示过程中按照用例或者按照流程去点，拉上 UI 产品等开会
提供自测用例，没有通过的就打回
mdd~
回复
首先，不是让你直接去找领导吐槽提建议，而是要在群众面前讨论问题，在群里和开发对话，将现状暴露在群体内，让领导自己去思考这种问题会造成的消极影响。
然后是我们能做些什么？
你可以参考 #9 的建议，每次迭代都开会让开发冒冒烟，我个人感觉这种方式不会是那么简单就能推动和延续下去的，因为我经历过；我现在做得也只是要求开发自测时需要执行覆盖所有测试用例并留存执行结果。
最后我确实给不了你很好的流程上的优化建议，因为人类是难以影响自己职责权利之外的其他人的，人类的本性从来都不是自控和向上的
让开发单元测试，测试提供冒烟用例，开发执行。提测后测试冒烟用例回归，如果发现错误率低于一定值，打回重新开发
1、形成流程规范，这种需要测试领导和开发领导认可，如果开发领导认可，他在他们组吼一声且作为绩效考核目标，我相信很多人都会照做着，形成一种好的风气
2、测试如果有足够的能力做提测卡点，例如自测覆盖率达不到 XX 不让提测，流程给你卡死，我看你还自不自测？
目前我觉得就这 2 种方式，其他的私下沟通啊都没效果，可能有的人能做到，有的人做不到
小公司很难搞，问题不是单一节点问题，而是体系、流程、管理、人员、迭代全链路多节点都存在问题，要想改善，需要花大量成本，还会影响版本迭代速度，那么就会引起上层领导的不满，小公司一般很难接受以大成本为代价的质量建设，当然浅层初期的优化质量还是可以做一些（比如简单的接口自动化），能让领导感受到你是有价值的，至于深入根治就放弃吧
建议从公司质量角度来推进，不要仅着眼于测试，在研发各个阶段参与进去，指定相关卡点，质量提升是团队的整体目标，测试是其中的一环，持续精进有改进有有希望；个人的话建议尝试代码走读吧，跟开发建立良好的信任下，沟通之间言语挖苦 bug 的低级；有条件的话尝试引入代码覆盖率，通过控制开发提测前的覆盖率与提测后的测试把控的覆盖率来体现自身的专业性
软件质量不是测试一个部门或者团队某一个人的任务，而是大家共同的任务。
首先要明白，领导的重视程度、团队的重视程度
其次，我们才采取科学的办法进行降低缺陷出现的频率
对于同类型的缺陷，做好记录分析好原因。让整个团队重视，首先分析同类型的缺陷是设计上还是开发规范上出现的，先减少同类型的缺陷
最后，“恐惧源于未知”