昨天一个偶然的机会,临时充当了下软件测试的角色,体会很深!也让我对软件测试人员有了更多了了解和理解,并对自己(开发者)也提高了要求。
开发、测试不分家,心在一起,劲往一处用就可以大大改变产品的质量。这个道理大家谁都明白,但是我们是做到了60分,还是90分呢?这是值得我们深思的!
情景1:
我拿到一个产品,让我测测,我首先根据自己的理解来测试这个产品,保证链接的正确,数据不敢保证,随着测试的逐渐深入,我发现,有些功能根本不知道是做什么用的。
感想:一个产品如果没有需求文档,就算有使用文档,那又有何意义呢?
情景2:
我找到了需求文档,对里面的内容进行查看,多多少少还是帮助了我理解了这个产品的功能,但是好多页面展现,无从考究!例如一些展现的关系图,是根据什么绘出来的?箭头代表什么?等等等等!总之给我的感觉就是功能依照使用手册会用了,但是不知道是用来做什么的!顿时你会想到,这些都是什么做什么用的?为什么文档没有写清楚?难道还要我逐条写下来,依依的问?
感想:情景2做到了60分,因为有了需求文档,但是这份需求文档,有跟没有差别不大,主要是解决了有、无问题。对于根本性的问题还是没有解决。
这时候想想我们自己做开发的时候,是不是以为这个很简单,我们组内都清楚,就没有写在需求里呢?现在想想,开发觉得自己明白的东西,往往别人是不明白的!看来以后写文档的时候,我们需要转换一个角度来写这个文档。逐渐达到70分!
情景3:
找到开发问了这个功能,开发简述一遍,是简述哦!大体知道这个功能是干啥的了,也能看到展现,但是展现的对错与否,谁又知道呢?
感想:测试点很重要,我们的展现对错,是要考虑测试人员对这个系统的理解,如果我们能够在文档中,写清楚测试点,那么测试人员就会更有依据来判断展现的内容是否正确了,如果做到这点,我相信应该可以打80分了!
情景4:
随着时间的推移,我烦躁了起来,感觉能用,不知道为什么用,每个功能都可用,但是如何串联在一起呢?看了产品的SPD,使用手册,没有对各个模块串联着用的一个概览,这让我和恼火,我当时心里只有一个想法,这咋测?没有需求评审吗?双方之前没沟通吗?
后来得知沟通过,需求是因为项目多,开发没时间,只是简略的说做了什么,没有说做到什么程度,什么效果!
感想:看来对需求的沟通事值得我们深思的,开会了、沟通了,依然没有解决问题。所以我觉得只要是会议,一定要双方达成一致,且一定要形成结论,不然那就是扯淡!话糙理不糙!就是这么个道理!
本以为这一天的时间是浪费了,其实不然,通过这一天的实际换位,真正的达到了换位思考的效果,理解了测试人员的苦衷,也了解了一些作为测试人员最需要的是什么样的文档,需要的是开发怎么的配合。同时自己身为开发人员的我,觉得在今后的开发中,一定要落实文档,积极配合测试人员!当然开发人员也有苦衷!但是我们需要先从自身找原因,解决掉自身问题,也许很多难题会迎刃而解也说不定呢?
注:一些感触,只对事,不对人。如有雷同纯属巧合!请勿对号入座!
开发、测试不分家,心在一起,劲往一处用就可以大大改变产品的质量。这个道理大家谁都明白,但是我们是做到了60分,还是90分呢?这是值得我们深思的!
情景1:
我拿到一个产品,让我测测,我首先根据自己的理解来测试这个产品,保证链接的正确,数据不敢保证,随着测试的逐渐深入,我发现,有些功能根本不知道是做什么用的。
感想:一个产品如果没有需求文档,就算有使用文档,那又有何意义呢?
情景2:
我找到了需求文档,对里面的内容进行查看,多多少少还是帮助了我理解了这个产品的功能,但是好多页面展现,无从考究!例如一些展现的关系图,是根据什么绘出来的?箭头代表什么?等等等等!总之给我的感觉就是功能依照使用手册会用了,但是不知道是用来做什么的!顿时你会想到,这些都是什么做什么用的?为什么文档没有写清楚?难道还要我逐条写下来,依依的问?
感想:情景2做到了60分,因为有了需求文档,但是这份需求文档,有跟没有差别不大,主要是解决了有、无问题。对于根本性的问题还是没有解决。
这时候想想我们自己做开发的时候,是不是以为这个很简单,我们组内都清楚,就没有写在需求里呢?现在想想,开发觉得自己明白的东西,往往别人是不明白的!看来以后写文档的时候,我们需要转换一个角度来写这个文档。逐渐达到70分!
情景3:
找到开发问了这个功能,开发简述一遍,是简述哦!大体知道这个功能是干啥的了,也能看到展现,但是展现的对错与否,谁又知道呢?
感想:测试点很重要,我们的展现对错,是要考虑测试人员对这个系统的理解,如果我们能够在文档中,写清楚测试点,那么测试人员就会更有依据来判断展现的内容是否正确了,如果做到这点,我相信应该可以打80分了!
情景4:
随着时间的推移,我烦躁了起来,感觉能用,不知道为什么用,每个功能都可用,但是如何串联在一起呢?看了产品的SPD,使用手册,没有对各个模块串联着用的一个概览,这让我和恼火,我当时心里只有一个想法,这咋测?没有需求评审吗?双方之前没沟通吗?
后来得知沟通过,需求是因为项目多,开发没时间,只是简略的说做了什么,没有说做到什么程度,什么效果!
感想:看来对需求的沟通事值得我们深思的,开会了、沟通了,依然没有解决问题。所以我觉得只要是会议,一定要双方达成一致,且一定要形成结论,不然那就是扯淡!话糙理不糙!就是这么个道理!
本以为这一天的时间是浪费了,其实不然,通过这一天的实际换位,真正的达到了换位思考的效果,理解了测试人员的苦衷,也了解了一些作为测试人员最需要的是什么样的文档,需要的是开发怎么的配合。同时自己身为开发人员的我,觉得在今后的开发中,一定要落实文档,积极配合测试人员!当然开发人员也有苦衷!但是我们需要先从自身找原因,解决掉自身问题,也许很多难题会迎刃而解也说不定呢?
注:一些感触,只对事,不对人。如有雷同纯属巧合!请勿对号入座!