业务沉淀_怎样做才能提高工作效率
最近一直都在考虑一个问题 但都没有想到好的解决方法对于一个庞大的系统来说,需求永远在不断的变化,不断的增加,而且增加 变化的速度越来越快,项目一个接一个的起来,大家都忙的昏天黑地,不但要做测试执行工作,测试执行结束后 还要完善业务知识沉淀,新的需求需要增加,需求变更 需要更新老的业务沉淀文档,而这个时间基本上都没有考虑在工作之内,刚做完这个项目,下个项目就已经在那等你了
针对业务沉淀发挥的作用到底有多大?我总结了几点 好处:
1.针对需求比较稳定的系统而言,沉淀是有必要的, 熟悉业务的人随着业务越来越繁多,以前的业务会偶尔忘记,所有沉淀下来方便查找(这点可以通过查找测试用例来解决)
2.方便新人来了 对其需求培训的时候,可以让他自己去看沉淀,节省了培训成本
3.其他产品线的同学需要了解业务,可以给出文档(但通常他们需要的不是很细的东西)
不好的地方:
1,问别人总是会比自己去看来得快,耽误了被提问的的人2分钟的时间,往往可能节省了提问者10分钟的时间,甚至他可能花了几分钟的时间后还是没有找到他想要的答案,针对一个团体而言,提问的方式会更节省团队的时间
2.沉淀写的粒度不一,针对上面提出的第2点好处,大多数新人看沉淀文档的过程中,由于每个人的语言描述存在差异,所以新人同样会提出很多问题,同样会耽误熟悉业务同学的时间
而新人入职的比例有多少?如果为了这些新人 而把业务沉淀写的很细,这就会给熟悉业务同学造成压力,会花掉熟悉业务同学多少时间?而往往熟悉业务的同学通常都承担着比较重要繁忙的任务
3.实际工作中,除新人,提的问题通常都是很细小的问题, 如果让他去看沉淀 不太现实,因为可能熟悉业务的人就是一句话就能解决了
4.业务沉淀库没有结构,过了很久 让业务沉淀的人去想当时沉淀文档的名字叫什么,也有点困难,通常情况下,都是自己先去沉淀库理搜下 然后在扔给提问者,而想这个名字也花费时
以上目前想到的几点, 比较纠结,不写又不行,有没有什么方法可以一举两得呢?如果不写沉淀,让提问者去找测试用例,但由于测试用例的结构相当的细,而且结构不清,不能梳理流畅
找起来也很麻烦
我想的理想状态就是,测试用例实现智能化,比如测试用例编写的时候 按照业务沉淀的结构来写
沉淀的内容结构通常是: 入口
操作流程
具体业务规则1,业务规则2.....
测试用例也按照这种结构,然后有个工具,按照这种结构 提取用例里的文字内容,这样就自动生成业务沉淀了
或者再用例上做个标识,提取文字内容的时候 只提取有标识的文字内容
当有业务变更的时候,只要更新测试用例就可以了,测试用例更新好了,然后重新提取生成业务沉淀
这样 只维护一份测试用例就可以了
就不用每次新项目 新需求做完 要硬着头皮忙的昏天黑地还要去编写或者更新业务沉淀,而测试人员最本质的工作是要放在怎么测好系统上,希望测试人员能把大部分的时间都投入在这个上面,而不是被很多的杂事(团队建设)所包围的疲劳不堪
上面提出解决问题的思路还不成熟,希望有遇到这样问题的同行们能一起讨论下 或者给出更好的提议 主要还是测试用例得写好、管好 这个不是用例的问题 应该算是团队建设的问题了
对于一个庞大的公司 庞大的系统，光有测试用例是不够的，面对繁忙的工作，面对一个接一个得新手，面对不熟悉这块业务的同事。。。需要找出更高效的办法来解决 业务文档建议还是要单独整理，可以和需求挂钩；建议一个业务或大的功能可以单独整理一份文档。
测试用例步骤可以写的颗粒度小一些，且测试用例是根据业务或功能整理的。这样的测试用例也可以承担起培养
新人的作用。
页:
[1]
