合理开发流程提高交付质量

最近有一位 QA 同学（测试同学）朋友和我吐槽他们公司的开发进度慢、质量差，后端开发4天，前端开发4天，联调4天。每个迭代快结束的时候才会把提交测试，导致功能根本测不完，要么延迟上线，要么只能带着 bug 上线，而线上如果出了问题还会被老板问责。

相信很多同学都遇到过同样的问题，这里有两个的问题：一是如何保障开发质量，二是合理的开发流程。

如何保障开发质量并非文本的讨论的主旨，可以简单提下。QA 并不能生产质量，开发才是质量的生产者，要提高质量就要把测试提前到开发过程中，之前写过一篇如何写单元测试，有兴趣的同学可以了解一下。

我们重点来看一下如何实现合理的开发流程。

迭代需求会

迭代需求会是在迭代开始前由产品经理组织的会议，需要开发同学和 QA 同学共同参与。产品经理会讲解这个迭代的所有需求，以便大家对需求的理解是一致的，同时确定迭代需求范围。

然后进行工作量评估，我们公司都是以估点的方式可以参考《用户故事与敏捷方法》中的方式，之前也有篇文章记录过。每个公司可以依照自己的方式进行评估即可。

Ps: 工作量评估之后可能会影响这个迭代的范围，各个公司情况不同。

开发之前

在我们公司与其他不同的有一个开卡的环节，开发者会找产品经理和 QA 进行开卡，产品经理会把这个故事卡的功能再次描述，大家理解的信息一致后开发者才会进行开发。

这部分看起来与前面的迭代需求会略有重复，但仍然是有必要的，一方面在需求会上功能较多信息量比较大，新功能不一定会由谁来发，开发同学关注的点可能不一致。另一方面对于新加入团队的开发同学，有些类似的功能在之前的迭代中开发过，在这里产品经理和 QA 在这里告知开发同学，避免重复开发。

通常一个需求都需要前后端共同来完成，我见过最糟糕的开发流程是后端先去开发，前端等待后端开发完成之后再进行开发…如此，想不延期恐怕都难。好在，大多数公司都会先定契约（接口）。我们可以根据契约生成 Mock Server，有了 Mock Server 前后端同学就可以各自开发了。

QA 同学在约定好契约后就可以准备测试数据、编写测试用例以及测试脚本，当然这部分测试是基于 API 的自动化测试。

此时前端、后端、QA 同学就可以同步进行自己的工作，不需要彼此等待。

QA 尽早介入

无论前端还是后端只要有一方开发完成，QA 同学都可以进行测试，不要等到所有功能都开发完。

如果前端先完成开发，QA 同学可以基于 Mock Server 的测试，根据不同场景的 Mock 数据来测试前端的正确性。当后端开发完成，只需要修改前端 API 的 host ，就完成了对后端的集成。

如果后端先完成开发，QA 同学只需要将编写好的测试脚本指向后端 API，就可以很快完成对后端的接口测试。

如何维护契约

可以看出契约对于开发流程的重要性。在开发新功能时契约还比较完整，后面有修改时契约的维护就要靠人们自觉维护，口头通知要比写在文档中的效率更高，时间越久文档越落后。只要靠人自觉的事情就可以当做没有，那如何才能保证契约文档的更新呢？

QA 同学的测试脚本起到了重要作用，只需把自动化测试放到 CI（持续集成工具）上，QA 只有跑过了所有测试脚本，才算测试通过。所以在后端同学修改了接口之后必须同步修改契约文档和 Mock Server ，以保证测试脚本通过。

总结

读过《持续交付》的朋友们知道，这仍是一篇入门级的文章，并非最佳实践的全貌。为了能够降低落地的门槛，只写了我认为比较关键的环节。值得一提的是，编写契约可以通过Raml 或 Swagger 这两个工具，Swagger 的生态更加完整，生成Mock Server 更加方便，后面有时间会写一篇 Swagger 的教程。

原文链接：https://xbl.github.io/2018/03/07/%E5%BC%80%E5%8F%91%E6%B5%81%E7%A8%8B%E6%8F%90%E9%AB%98%E4%BA%A4%E4%BB%98%E8%B4%A8%E9%87%8F/