软件测试风险管理

发表于:2011-11-04 11:16  作者:梨花落(sinablog)   来源:51Testing软件测试网采编

字体: | 上一篇 | 下一篇 |我要投稿 | 推荐标签: 软件测试 测试风险 测试管理

  好像所有带有‘管理’字样的东西都变得不那么具体了。

  一般这个东西就要对症下药了,所以首先得知道有什么样的风险。在实际的工作中主要遇到过以下的风险类型:

  1、需求变更,这个是最大的风险,因为最后期限是不变的,需求变了,就意味着更多的工作要在已计划好的日程表中做完。风险可排老大

  2、人员变动,在一个可以持续2,3个月的项目中,中途可能有人离职

  3、需求理解问题,由于缺少行业知识,业务背景,有可能对需求的认识不够透彻

  4、复查工作没做好

  5、需求覆盖率不高

  6、测试用例执行没有达到100%

  7、测试环境和实际环境有偏差

  8、测试缺陷很难重现,导致无法定位根源从而没有修复

  针对第一条:估计每个公司都在这上面吃过亏吧。所以才有那么多的软件开发模型。我所经历过的一些比较大的项目,采用的都是增量迭代的开发模式,所以在每一个小的阶段,需求是相对稳定的。但是也有变更的时候,这种时候,我们一般是要求走需求变更流程,根据变更的大小来确定策略:如果变更造成的工作量小于3天/人,作为一个ADHOC项目,如果大于3天/人,就作为另一个新的项目。这个当然要和客户达成一致。

  针对第2条:最好是每个岗位培养备份的人员

  3,4,5条其实可以归结为一条,我们尽量在需求分析阶段就把自己所有不明白,不清晰的问题提出来,整理成一个文档,先内部回答,这个内部可以包含开发,然后发给需求方请求答案。测试用例评审会要组织好,在开始之前,要求每个人所设计的用例至少被2个不同级别的人员评审过,然后再评审会上确定最终的问题和解决方案,会后跟踪这些评审会上出现问题的状态。

  第6条是完全可以避免的。如果时间确实很紧,按优先级别选择最重要的CASE去跑。

  第7条嘛,一般是在搭建测试环境之前,列出一些需要检查的项,搭好后,让人按这个检查项一项一项的去检验。

  第8条,还真没什么好办法,如果你有,麻烦告诉我下。我们一般遵循的是只要是出现过的,哪怕一次也是缺陷,都要记录在案的。也可以在交付客户时说明并一同交付。

  说在最后的,做测试肯定要得到老大的支持和重视,否则风险控制都是空谈啦。尽量每个阶段都要文档化,规范化。

  做任何事情都有风险,风险管理无非就是消除,消除不了就减少,减少不了就降低。降低到一定程度就不再有威胁,或者短时间没威胁,没威胁就不是风险了。

  针对测试的各种风险,还是建立一种“防患于未然”或“以预防为主”的管理意识比较靠谱。

  此文为个人经验,不对之处请指教。


评 论

  • coyi (2011-11-05 17:38:07)

    领教了

论坛新帖

顶部 底部


建议使用IE 6.0以上浏览器,800×600以上分辨率,法律顾问:上海信义律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2021, 沪ICP备05003035号
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪公网安备 31010102002173号

51Testing官方微信

51Testing官方微博

扫一扫 测试知识全知道