软件测试是找BUG,不是找茬

来源:互联网 发布:测试 软件迭代 编辑:程序博客网 时间:2024/04/28 18:01

         做测试久了,经常会有一些感悟,最近在51上看到一贴,说出了我的心声,把我一直想写却一直以时间为借口为由拖着未写的心声写出来,摘抄了部分过不,一起纪念测试的年代,测试的心声。测试好象一直会被一些人误解:测试就是找茬!

            经常被问到“你是做什么的?”,回答“测试”时,别人马上反问“你会不会编软件呀?”。我说:“不会,我是做软件测试的,不是做开发的!”接着又问:“你是专门挑毛病的,是吧?”我只是笑着摇摇头,说:“我做软件测试,是找缺陷,不是找茬!”做测试久了的大家可能都会有些这样的想法,下面这二段是摘的,但是也有部分是我的心声。

  第一:软件测试是找bug,不是找茬。以前在外包做测试,面对的之间人是PM,面对所谓的客户是开发软件的人,而且因为离开发人员较远,沟通基本上都是用邮件,所以当时的感触还不太多,只是做好自己的本职工作,尽可能的发现更多的问题,尽可能让自己发现的问题更有价值,尽可能让自己发现的问题让开发能够百分之百复现!现在进了一家自己做产品的公司,面对的人整个全变了,以前以为面对的是开发,现在明白在自己做产品的公司了,不仅要面对开发、还有产品、设计、还有真正使用的客户!以前总是听说测试和开发是死对头,很难沟通,也看了很多关于开发和测试之间沟通的问题,其实真的没有什么对头不对头的,因为大家最后的目的是一样的,都是为了能把项目做好,测试希望项目好,开发更是希望它成功!就像我前两天看的一篇文章,说开发其实跟测试一样看中产品的质量,因为他们是真正实施的人,谁不希望自己做的东西能尽量完美呢?而开发为什么会跟测试有隔阂呢?是因为开发想让测试第一时间就能找出那些关键致命的bug,而作为测试本身呢?看到的每个问题都会及时的去上报,只是分了优先级别,而开发却不看这些所谓的优先级别,所以就会认为不好好的找重大bug,竟在挑刺,其实每个角色都各自体谅一下就都解决了,既然目的是一致的,为什么非得在纠结这个先后顺序呢?开发的,不要以为测试人员是在故意找茬,他们提出来的问题应该都是缺陷,只是处理的轻重缓急你们自己来决定就可以了;而测试的,也不要以为开发人员是对自己有意见,在提交bug的时候,最好先挑那些重大的bug,震震开发的,然后在把那些不太重要的问题一起报上来,这样不仅仅测试的价值体现了,而且开发也会对你另眼相看,同时大大的提高了测试的地位!要时刻记得,我们测试是在找bug,不是在找茬!

  第二:软件测试只是提高产品的质量,而不是保证产品的质量。我记得我第一次接触测试,在课堂上我的导师就跟我说“我们测试是提高质量,而不是保证质量。”而有很多不太懂测试的人就会产生一种误解,认为要测试的干嘛啊?既然我们花了钱用你,就应该保证我们的产品没有缺陷呀!对于这样的人,我只能说不太理智,并不是我作为一名测试人员推卸责任,而是因为这个世界上本身就没有百分之百的事情,我们能做的就是尽我们的全力去提高、找出最多的问题并得到相应的解决,测试不是万能的,如果有人说我测试,能保证你们产品的质量,那我只能说你被忽悠了,我们只是提高产品质量,而并非保证产品质量!

  第三:软件测试是需要全民参与的,而并非只是测试工程师的事情。有人认为反正有测试人员了,所以对产品就不太关心了,其实测试是每个人的事情,其中也包括了客户,因为一个人再细致也没有无数双眼睛看的全面。忘记了是哪个公司的老总一直提倡的是全民的测试意识,我觉得很赞,因为每一位员工都是一份子,而做的每一个产品不仅是公司的形象,也是我们每一个人的体现,只是我们的分工不同而已,但是它都代表着我们,而且我觉得这样的管理观念还可以有团结人的力量,可以让大家一起把事情做的更好!而不是单单的依赖于测试,最后把大家变得越来越懒惰,我发现现在的公司就有这种现象,开发人员有时就会有一种依赖的心理认为反正有测试呢?对于自己写的程序也不那么太认真了,而且自己做完也不是很认真的检查了,拿过程序来,随手一抓都是bug。最后弄的开发头疼,测试也头疼,所以说公司要从根上来激励这种意识,测试不仅仅是测试工程师的事情,而且是需要全民参与的一个重要事情!

      个人愚见:测试确实需要全民参与,才能更好的提高质量,每个人的思维方式,掌握的业务水平不一样,大家站的角度不一样,当然能发现更多系统的问题;同时要想提高质量,还得从源头抓起,也就是在设计时,就要下苦功,有了好的基础、框架,再往上搭的时候会轻松很多,我们经常遇到在系统测试的时候,提出的一些问题,开发给出的解释是,这个是框架的问题,没办法改,那个是什么逻辑问题,也不好改,我常常就在想,为什么在设计阶段不多研究一下呢,设计未过,就马上进入到编码阶段,最后出来的程序,没有一个统筹,而是各自为政,导致出现的问题,在后期要修改起来很为难,到底要不要改呢,如果改要耗费大量人力、时间有可能冒着延迟进度的风险,而不改又确实是个问题,如果在客户使用时发现提出来这个问题时,到那时,我们该怎么办?

     对于开发与测试人员关系的问题,这个也是感悟很深,以前有遇到个别的开发的人员很烦测试,这个是小问题不想改,那个也是小问题不想改,只有影响到功能不能实现的才是问题才会改,或都调整样式等这样的问题很烦,不想改等等。各种各样的问题都是需要测试人员把握的,这些问题最好在后期与开发人员强调,沟通协调修改,在前期尽量提一些功能缺陷方面的,这样配合开发人员实现整个系统的功能,其他的在后期再来调整,因为开发人员的想法就是功能未实现,调样式有什么用,或许后期还会有一些修改呢,担心调了也是白调,误了时间,现在我也能理解了。前期如果我们能发现一些逻辑上的问题,或业务流程考虑不周的问题行装,开发人员还是挺重视的,也会很愿意和我们沟通,系统有了什么调整也是第一时间通知测试人员,对测试人员不再有敌视,更多的是一种依赖。

        做测试久了,发现自己要学的东西太多太多,真正明白了,为什么帖子上常见问题:测试人员应该掌握的知识。如果有一个缺陷,那对测试生涯真有挺大影响,如果掌握的知识越精通,对所测的系统也会更全面,也能和开发人员进行更多的沟通,不然开发人员就只会认为,测试只是测测表面的问题,测测界面,没有多少实际的意义,这样当然得不到重视了。今天就写到这里了,有时间再来补充吧。

      不管开发,还是测试,更甚于公司,因为我们的目的是一致,就是提交给客户的是一个高质量的软件,为了我们的共同目的,让我们一起加油!