7、如何提高RD代码质量？

　　challenge：提高代码质量、降低RD和QA的人力比！

　　提高RD代码质量对QA来说是一个亘古不变的问题，路漫漫而修远兮。。。

　　目前我们的解决方案是：要求并监督RD做单测和集成测试。终目标为测试驱动开发（TDD）。

　　在敏捷团队中，QA的负担已经很重了，此时应该果断把之前从RD那边分担过来的集成测试自动化（IT）再还回去，并且推动RD把单测（UT）落地，从而提高RD的代码质量，降低bug率，减少回归时间，终降低RD、QA人力比，成为真正的敏捷QA。

　　A）UT

　　完全由RD编写，目前QA正在对RDs进行一对一的单测培训，将对RD整体的单测水平有很大提升，目前已有RD为提高代码可测性进行了代码重构。培训完成之后，将对RD单测覆盖率会有一定要求。后续所有单测将会被加入到quick build中。

　　B）IT

　　新增代码的IT将全部由RD编写，QA对其进行review，有时间的话会帮助RD设计一些case，由RD来实现。

　　IT被作为story达到提测质量的一个必要条件，RD必须对story中新增功能的验收条件达到全覆盖。

　　C）ST

　　ST由QA负责，目标是覆盖所有的主干流程，既可弥补自动化覆盖不到前端代码的不足，又能减少QA回归工作量。

　　8、没有准入，怎么保证提测质量？

　　challenge：没有准入，RD提测质量太差怎么办？

　　以前的瀑布流程，为保证提测质量，QA会做一个准入冒烟，通常一个模块几个case，如果case pass率小于85%，则会打回。QA在准入测试也会花费比较大的时间成本。

　　如今story粒度相对较小，提测太频繁，做准入是不太现实了，但提测质量还是得保证，经过不断地摸索，我们的应对措施为，限定卡片从开发中移动到待测试必须满足的前提条件，具体如下：

　　1）QA将提测story的验收条件分为两部分（ａ、新增功能；ｂ、原有相关功能）

　　2）RD提测之前，需保证所有验收条件通过，否则视为提测质量不合格，产生的ｂｕｇ在迭代回顾会议中进行总结学习。

　　3）RD提测之前，需保证验收条件中所有新增功能的service层代码，都被自动化集成测试case覆盖，若有特殊情况，提测时需做特殊说明。若QA review时不满足新增功能全覆盖，将在迭代回顾会议上进行case study，后续还得使用工具保证。

　　4）RD提测前，需完成必要的单测（还待完善）

　　5）RD提测前，需要进行复杂逻辑的CR，CR规则还在试行中。

　　使用以上的5条，不仅保证了提测质量，且QA几乎不再需要为准入投入时间，同时，集成测试被落地后，后续的回归工作也会慢慢减少。

　　经过两个迭代的试行，bug量显著降低了，取得了不错的效果。