• 软件测试技术
  • 软件测试博客
  • 软件测试视频
  • 开源软件测试技术
  • 软件测试论坛
  • 软件测试沙龙
  • 软件测试资料下载
  • 软件测试杂志
  • 软件测试人才招聘
    暂时没有公告

字号: | 推荐给好友 上一篇 | 下一篇

说服研发修改bug

发布: 2009-11-02 15:00 | 作者: webmaster | 来源: 本站原创 | 查看: 54次 | 进入软件测试论坛讨论

领测软件测试网

说服研发修改bug      软件测试

没有什么时间写东西了,原来很多好的想法,都不能系统的进行阐述,只会在看到有的贴子时,给一些零星的回贴,这一次居然得了个每日一问二等奖,看来此回贴还是受到认可的,看了一等奖(ID:sun_0910)的回答,真的很棒,很有一些严禁的味道,思考特别全面,一看就是特牛P的权威人士,一看就是受过极正规的训练,这种写文章与做事的严谨作风值得大家学习,而我的个人的文章风格就是喜欢简单化,口语化,形像化,具体化,但在工作上就应该像sun_0910一样才好,而且我是一个测试领域的法家份子,也希望能将法家的思想与质量测试理念相统一,一家之研究吧! 

      由于我做过两年的开发,5年的测试,在测试过程中,自己也做过些测试工具,也有测试人员对我的测试工具来进行测试的经历,所以我首先站在一个开发人员的角度来看,什么样的bug与测试人员能说服我呢?要说这个问题,我们首先要有有一个假定:假定开发人员不是一个神经病(多数其实都不是,如果是,那么应该由人力资源部负责),既然开发人员不是神经病,那么你一定要相信他对于自己所做的模块也是抱着认真负责的态度,希望把功能顺利实现,而不会出现什么意外状况的,所以当有人给我提出一个bug是我确实没有想到的,而又实在的影响到这个模块的功能,我做为一个开发人员会考虑修改这个问题,如果这个问题还有一点点深度,我会更加开心,抱着挑战的态度,也抱着赶快把此功能搞定的急迫心情去修改它,由此得到一个好的绩效与认同,所以像这样的bug,需要测试人员来说服我么?当然不需要。然后再看看什么样的问题我不喜欢,曾经我做过一个测试工具,新来的测试人员对我的工具进行了测试,在测试的同时,也使新人学习了各种业务知识,在这些测试者中,我就很明显的对那种能提出功能性错误,或者我考虑不周造成的错误(这一定要用专业的测试方法才能测出的)的新人,我会报着一种对他的欣赏的态度去修改他提出的问题,而对那些,没事找事,总是按自己的主观意愿提出一些使用上问题的人,给以鄙视,比如新来的测试负责人,在我修改完所有问题后,叫我把下拉框改成tab页,嘿嘿,你喜欢tab页,我就喜欢下拉框,测试部难到没有别的事情做了吗,做这么无聊的事,也就是说,有关操作习惯问题本就是你有你的习惯,我有我的习惯,凭什么就说你的习惯是代表了广大人民群众呢?是吧?

      看了上面一段,相信大家就知道了什么样的问题会得到认同,这样的问题,根本不用你去说服谁,但是,这个世界如果如此简单,就不会有战争了,是吧,所以,我刚才说的只是开发人员的立场,说这些只是让大家明白一个心理特性,并不意味着,开发人员的这种立场在任何场景都是正确的。

      所以,还有一个测试人员的立场问题,对测试而言,我们有各种测试方法去发现bug,有时有的测试方法做出来的测试结果确实发现了问题,但这个问题可能会引发开发人员的反感,这是因为开发人员对测试的工作不了解造成的,比如,我们用边界测试发现一个问题,但开发人员会说,谁会去输入这样的数值呢,在实际工作中,人家是不会这样操作的,所以拒绝修改这样的问题,怎么办呢?这个时候,其实如果一味的让每个测试人员去与每个开发人员讲道理做宣传,其实效率是低下的,而应该把这一类问题记录下来,由测试部门进行一个评估,然后与项目负责人进行沟通,在一个适合的时间点(致命问题、严重问题都改得差不多且还有时间的时候),对此类问题进行一个全面的修改,如果是一个好的公司与部门,还会就此类问题进行总结归类,并对此类问题定义出严重程度与修改的优先等级,如此就完成了一项过程改进,当下个项目出现类似的问题时,一个制度化的结果已经在这里了,开发人员再次见到类似问题,自己就会在已经把致命与严重问题修改完成的情况下,对此种等级的问题再进行修改,而不需要再次做没有必要的沟通了。再比如使用操作性问题,其实就是一种体验测试,如果这种问题由每一个测试人员零星提出,不但没有科学调查与说服力,也会得到开发人员的白眼,所以有关使用方便的问题,也应该单独的当成一个整体事件去做,而立下科学调查的标准化决议,当项目组与测试部与市场都搭成统一标准后,做这些事,还会有阻力吗? 


      我看有的人的解决方法是人情世故,有的人的方法则是权利压人,还有的人的方法是每回都去以理服人(以德服人,怎么感觉测试总是低声下气的?难怪人家不改你的问题),还有总总方法,但不是有后遗症,就是回回都要如此,搞得效率低下,所以真正的方法应该是,把一项不太受到开发人员重视,但又确实是不可小视的那些问题,想办法通过外交努力,搭成统一的科学的标准化的制度化的行业规范,当一个制度在这里时,没有人会觉得你是和他过不去,只会觉得,这是制度的要求,我们本就都该这样做,就好像你迟到了,你不会认为是人事MM对你有偏见,也不会认为人事MM水平低,不懂得以人为本的道理吧?当然不会,因为几点上班是一项制度。有人见过搞人力资源的人在网上发贴问:请问人事如何更有效的说服员工们不要迟到呢?呵呵,一家之言哈!

延伸阅读

文章来源于领测软件测试网 https://www.ltesting.net/

TAG: bug BUG Bug 研发


关于领测软件测试网 | 领测软件测试网合作伙伴 | 广告服务 | 投稿指南 | 联系我们 | 网站地图 | 友情链接
版权所有(C) 2003-2010 TestAge(领测软件测试网)|领测国际科技(北京)有限公司|软件测试工程师培训网 All Rights Reserved
北京市海淀区中关村南大街9号北京理工科技大厦1402室 京ICP备10010545号-5
技术支持和业务联系:info@testage.com.cn 电话:010-51297073

软件测试 | 领测国际ISTQBISTQB官网TMMiTMMi认证国际软件测试工程师认证领测软件测试网