前言

项目的任务质量如何保证？在我看来，主要取决于以下这几个环节：需求要明确、任务开发时间要合理评估、任务需提供测试用例、在项目进度会议上进行功能演示。产品质量是生产出来的，不是检验出来的，不可能全都依赖于验收环节，毕竟那时已经晚了。验收环节只是为任务的质量加了一层防护，应从源头开始，就要不断地关注和解决存在的问题。

需求要明确

需求要明确，这一点在前面几篇文章中都反复提到过，这里就不再赘述了。简而言之，就是产品的需求要具体到可量化的程度。比如我要买苹果，应该是我要买10斤XXX牌子的苹果。

任务开发时间合理评估

在评估任务开发时间的时候，要根据实际情况，不能过于宽松。比如一个设备列表的功能排个两三天就差不多了，硬是排了一周多，这显然是有问题的。但也不能太严格，比如就给一天的时间，这就存心为难他人了，大可不必，实事求是就好了。

有人觉得开发任务只要时间够长，那么交付的功能质量一定就更好，实际上并非如此。人性本就如此，很少有人会提前完成任务，大部分人都会压到最后一刻才说做完了，不过，这也没什么可指摘的，人之常情。

所以，任务开发所需的时间，通常以一个“跳一跳能够够得到”的要求去评估即可。

**我们不会要求一个只能跑10公里的人去跑马拉松，我们只会要求他不断地跑到10公里、11公里和9公里，而不是他每次都只跑了5公里。**道理是一样的，没有什么是十全十美的，只希望每个人都能在自身能力范围内做到最好，仅此而已。

任务需提供测试用例

我们开发人员在开发完成之后，就匆忙提交任务进度为100%，意味着任务已经完成了。但是在验收人去验收的时候，还是经常发现这样或那样的问题。

为了解决这个问题，就需要把全部的问题都放到明面上，而不是藏着掖着，让大家都能清楚地知道，哪些功能确实是真的验收了。

这就需要开发人员在开发完成这个功能之后，提供一个自测报告，也就是在AgileTC测试用例管理平台编写这个功能的测试用例（在《AgileTC测试用例管理平台的基本使用》这篇文章中有介绍过如何使用），把全部功能要测试的点依次列出。

这样验收人在验收功能时，就可以根据这个测试用例，把全部功能都过一遍，有规范有依据，不会像之前那样混乱，到底哪些功能是没问题的，哪些功能是有问题的，一目了然，沟通效率也会更高。

以微信读书PC端的功能为例，图一为微信读书PC端的页面，图二为根据功能编写的测试用例，如下所示：

什么时候编写测试用例

上面提到的是在任务开发完成之后再编写测试用例，但如果在需求阶段就编写测试用例会不会有什么问题呢？

在需求阶段就编写测试用例，这种开发模式就是常说的TDD（测试驱动开发）模式。这个方式当然是可行的，但存在一个问题，就是最终交付的功能和最初的需求可能会有出入，导致之前编写的测试用例不能用了，需要重新编写。

首先，开发人员在需求阶段就编写测试用例，相当于在对需求进行分解，同时对需求也会更加了解，能和产品明确，达成共识，避免接下来出现返工的情况。

总体而言，测试用例等同于列出需求点，后续需求有变更，也不是全部测试用例都不能用了，很大概率只是个别测试用例进行微调而已。

所以，不管是在需求阶段还是开发完功能之后再编写，在我看来都可以的。

说到底，测试用例最终还是要围绕需求来编写，从需求中提炼出的测试要点才是真实有效的。所以，**对被测对象业务的熟悉程度，也决定了能否设计出高质量的测试用例。**毕竟，各功能点之间往往都是有关联的，会隐藏很多被我们忽略掉或者是想不到的测试用例。

在项目进度会议上进行功能演示

我们发现只有在项目进度会议上进行功能演示才会发现问题。开发人员通常口头上说“已经做完了”，这很有可能是片面的，并非开发人员存心欺瞒，只是每个人对需求的理解，有可能一开始就有差异，这种差异即便功能已经开发完成，还是可能会存在。

在项目进度会议上进行功能演示，整个项目团队的人员都可以看到，并且可以随时提出问题，虽然这样会增加会议的时间，但我相信这是值得的。

这其实也就是在敏捷开发模式中提到的Sprint Review环节，简单来说，就是解决颗粒度对齐的问题（笑），能让项目团队中的相关人员，包括但不限于产品、研发、测试和需求提出方等参与验收当前开发的功能，确认是否有需求理解偏差或潜在的需求调整，能够及时反馈和沟通，有助于项目下一步的功能优化和工作安排。