大家去面试的时候,特别是一些创业型的公司,都会在面试时问你如果没有需求文档怎么做测试,看似这个问题是在考你的整理测试逻辑性,但是往往大家都会忽略的一点:为什么会没有需求文档?没有需求文档会有哪些问题产生。

当然在实际生产中,大家对这些问题基本都是避而不谈,以快速迭代为目的,口头的就把工作安排了。而危机,往往就是这么产生的。

对于这样的场景可能大家都很熟悉:项目经理或者产品经理(产品狗)口头或者简单记录一下软件产品的大致要做的功能,直接就开始大概排期。

这种开口就干的方式,看似简单高效,便于直接沟通,能够快速迭代。却不知,发现没有一份正规且实时更新的功能需求设计文档,会付出三四倍的代价来弥补。

最终会引发一场产品、研发、测试、UI之间的混战

但是,出来混,“偷工减料,都是要还的”。

所以,面对这个问题,你的回答要包含3个方面,不能只在“我怎么做测试这个层面上”

我们来看看

没有需求文档会有哪些问题产生?

1、增加团队沟通成本如何要让团队里面的所有人员对软件产品的功能需求设计有一个共识?当项目的团队人员越多,沟通成本就变得很高。

几乎是所有人的一个通病:以为自己了解了一小块需求就立即开始埋头干......最终很可能与项目经理和客户真正想要的功能相差甚远,因为每个人的理解不同。

写错了就要改,项目就会延期,势必导致测试时间不够用。这样的反复沟通下,会付出比之前多2倍以上的时间成本。

2、任务进度安排和分配不合理

这个需求该文档也是任务进度安排和分配的重要依据,都不知道具体要做什么东西,哪能拿出合理的任务进度计划。

3、如果需求变更,陷入恶性循环软件在开发过程中难免会遇到功能的需求变更,需求变更后基本都要推翻重弄来,如此恶性循环下,又是一场充满硝烟的战争。

其实我们测试团队应该在项目开始时就应该介入,而不是在产品开发完成之后。

测试团队应该对功能需求设计文档充分了解,且以此来编写具体的测试用例文档。

否则,只能是在界面上进行简单的表面测试,而真正的BUG并不在表面,这些BUG会藏得很深,等发现的时候可能已经造成很大的损失。

测试团队想覆盖全部的测试用例此时已经相当困难,他们甚至都不知道产品有哪些功能。

测试用例应该尽可能详细,尽量保证测试用例走完能确保产品能上线发布。