从做测试过程中发现,一般没有需求说明文档有3种情况
1、开发人员的意识不足,开发流程不规范,可能是以前做项目一直都是拿到市场可行性分析,然后项目管理人员进行简单模块划分,任务就分配下去了,更不就不写需求文档,或者只是简单书写大体功能点。
2、项目进度紧张,后期需求变动可能比较大,来不及书写详细的需求文档
3、项目是从原有项目上进行迭代开发,开发人员认为不要再进行需求文档编写。
针对上述2点提出个人意见:
对于第一种情况:
1、测试负责人应该坚持开发没出需求文档,就不进行测试,要坚持让开发输出项目需求文档,哪怕是写的不够详细也好。
2、需求文档要进行评审,评审做会议记录,并有专门人员对需求文档进行修改
3、最后就是测试人员进行测试需求分析,再根据测试需求点进行测试用例编写了。
对于第二种和第三种情况:
1、测试人员尽量找到已存在的资料,比如市场调研书,可行性分析报告,收集一切对项目有用的文档。并提出其中的功能点需求
2、如果是迭代项目开发,则找到前期项目的一些需求文档,概要设计,详细设计,测试需求,用例等。提起里面的功能点
3、咨询相关人员,获取项目一些大体功能,最好能知道大体项目的框架,然后记录咨询到的功能点。
4、了解项目大体框架后,可以在网上寻找同类产品,把里面的一些亮点功能点进行提取
5、整合上面的几点,测试人员应该书写一份你认为的测试需求点,然后分发给每个和项目有关人员,如测试人员,开发人员,市场人员。组织进行一个会议评审,在评审中详细记录修改的地方
6、最后整理出一份评审过的测试需求点,进行设计测试用例。
没有需求文档对于编写测试用例来说,确实很困难,做为测试人员,在没有测试需求文档情况下,我们不能等着开发人员输出,应该主动点,尽可能去多了解项目的一些情况,多知道一点,对测试用例就能多写点。
另类的方法:
我们推荐的解决办法有:
办法一:由开发部门补充文档,可以不要求太正规,只要让测试员想得清楚:什么输入应该产生什么输出就OK了。
办法二:测试员只是设定用例的输入,输出全部设为FALSE,然后由开发部门设定输出。
办法三:由开发部门做基本功能测试,测试部门补充用例。由于已有基本用例,测试员根据现有用例就可以判断程序功能。
办法四:程序员编码时,边开发边测试代码的基本功能,测试部门只是补充用例。与办法三的区别是:办法三是事后测试,办法四是测试驱动开发。
越是排在后面的办法,推荐指数越高。如果这些全部做不到,那我的最后建议是:重新考虑测试是否值得。