当产品人员把制订好的需求文档发给开发人员和测试人员之后,开发人员是不是就可以直接进入代码开发阶段呢?当然不是,接下来,先看一个示意图,如图3-2所示。
从图3-2可以看到,产品人员制订的需求文档发给开发人员和测试人员后,并不是直接进入开发和测试的相关工作中,而是先由产品人员、测试人员、开发人员三方共同评审这个需求文档。为什么要对需求文档进行评审呢?原因如下。
(1)需求文档毕竟是一个文字描述性的文档,开发人员和测试人员在阅读它的时候可能会有不同的理解,如果开发人员把需求文档理解错了或者漏掉了某个需求细节,那么开发出来的产品一定不是产品人员想要的,那问题就严重了。
图3-2 评审需求
(2)如果测试人员把需求文档理解错了或是理解存在偏差的话,那么测试人员就会按照错误的标准去测试软件,结果可想而知,测试人员提的问题都是无效的,都是在做无用功。
(3)对于产品人员制订的需求文档,开发人员和测试人员不能想当然地去理解它,而是要由产品人员召开需求文档评审大会,项目组全体成员参加。评审的方式一般是这样的:产品人员对需求文档中的内容一一进行讲解,如开发人员和测试人员有不清楚的或有疑问的地方都要及时提出来,然后产品人员解释其中的意思。当然,如果大家对需求文档有新的看法和建议,也可以提出来,最终由产品人员决定采纳与否。需求文档评审的目的在于消除歧义,完善需求细节,最后达成共识。评审完后,产品人员就会重新整理需求文档,最后形成一个标准的、统一的需求文档,分发给开发人员和测试人员。
在开发人员和测试人员拿到已通过评审的需求文档之后,他们便进入各自的工作流程,这里再简要地描述一下他们的工作流程。
(1)开发人员会根据这个需求文档去编写概要设计文档。什么是概要设计文档呢?打个比方,你想建个房子,那你得把这个房子的整体框架先画出来,软件的概要设计文档就像是房子的整体框架。写完概要设计文档后,你会根据它去编写详细设计文档。为什么又要写详细设计文档呢?继续打比方,房子的整体框架设计好了,接下来就要针对大框架内的一些更小的框架进行详细设计,如建房子之前的详细图纸,软件的详细设计文档就像是这个详细图纸。当然这个比方不一定恰当,只是为了便于大家理解。有了详细设计文档,开发人员再来编写代码就容易多了。当然,开发人员的这些工作暂时与初级软件测试人员无关,大家了解一下就可以了。
(2)测试人员拿到已通过评审的需求文档之后会开展什么工作呢?从图3-2可以看到,测试人员会根据需求文档编写测试计划和测试用例。什么叫测试计划?测试计划包括什么内容?什么叫测试用例?如何设计测试用例?对于这些问题,大家暂且不用担心,后面的章节将会对测试计划和测试用例这两个概念进行详细讲解。