何为“转测”？
就是开发人员开发完软件（功能）后转交给测试人员进行测试，通常会伴随一封转测邮件。
转测邮件内容通常为测试团队对开发作要求，主要内容为：转测内容（变更带上影响范围），转测包（软件/地址），负责开发人员，以及一些必要的附件（如sql脚本、配置说明手册等）。
转测后的一些怪象
冒烟测试 都无法通过，大概率程序连调试都没执行，使得测试流程阻塞。
开发转测的功能压根没实现。
转测的质量非常差，出现许许多多低级bug，测试随便一点就是bug。
如何提高转测质量？
引入绩效考核？简单粗暴，但并不值得提倡，虽然短期看起来有用，但并不利于工作的顺利开展。
那应该怎么进行呢？
下面结合实际经验谈谈一些可行的做法：
1、向开发leader布道质量意识
众所周知，每个物种更容易服从来自首领的命令或要求。如果测试直接给开发提要求，哪怕你很牛，也难免被抵触。
所以，我们最好的方式是，平时多向开发leader布道质量意识，让我们的测试思想和理论获得来自开发leader的认同。后面我们需要对转测质量作要求时，直接获得他们的支持，让他们对下面提出明确要求，更容易被开发人员接受、认同。
2、要求开发进行自测
把冒烟测试用例抽出来，写成开发人员可以理解的集成测试用例。当开发人员转测前，需要执行这些用例，并标记“通过”。（用例通过情况，需要以附件等方式放入转测邮件）
3、让“乱”走一阵
当一个团队没有意识到转测糟糕的质量带来的危害时，很难对他们作出这样、那样的要求。有时还得眼见“乱”，容忍“乱”，当大家都意识到需要改进时，我们再顺势把转测质量要求提出来，这样才能得到各方的支持。
4、做好bug分析
定义清楚哪些bug属于低级bug，并做归纳统计，最终以数据呈现出来。可以在项目总结时，给出这样的一份数据，并做好原因分析，通过团队的整体压力让开发对转测质量做出改进。
最后，你所在的项目团队软件转测质量高吗？有没有更好的方式，不妨留言一起探讨学习~
-- End --
文末寄语： 纹丝不动的生活，一成不变的工作。付出努力过，亦非自己期望的结果。爬上眉梢的白发印证生活的路艰难曲折，唤醒沉睡的斗志亦让我鼓足勇气做出选择。