作者在这篇文章中,列出了七个项目,指出怎样的开发人员,才是测试人员心中的好的RD.1.不要考验你的测试人员即使你和测试人员的关系不好,也不要故意制造bug,来考验你测试人员的程度.2.自己做自己的验收测试通常开发人员知道要去进行单元测试,但是往往忽略了GUI测试以及usabilitytesting.建议开发人员每次要记得去进行小规模的验收测试,来及早发现一些usability的issues3.不要
有人说若是QA早一点开始加入项目,应该可以帮助项目质量变好,可以帮忙厘清需求,可以缩短测试时间.听起来真的好处多多.可是真的是这样吗?我想以各位看倌多年的经验,应该会觉得不会这么容易.是的,是不容易,但是原因是什么呢?就我个人观感第一个原因是mindset,是的,是mindset.像我现在在runAgile,如果大家对Agile有所认识,应该知道Agile强调就是mindset的转变,如果心态没有
很多人常常问,如何得知testcases是否已经开得足够了,是否已经cover所有的范围了,这还真的是很难回答的问题,但是也是各很值得大家一起讨论的问题.因此小弟在此先抛砖引玉,先列出一些个人的看法,希望大家能够一起参予讨论,贡献一下不同的想法1.Requirement-TestCasesMapping常见的手法,是建立requriement/design和testcase的对应关系.这样你便可以
QA需要具备的第三个能力,是需求分析.需知道RD的工作通常是研究某种技术,并且负责实作某些moduleor功能.他钻的很深,但是全面性可能不够.所谓全面性,是指对于产品整体功能的了解度.通常他只熟悉他所负责的部分,其他部份的操作可能不太熟悉.就算即使是他的部分,若是加上对于环境的影响,或是使用者可能遭遇的问题,他可能也不见得很熟.可是QA不同,他需要测试大部分的功能,或者说他需要组合不同功能来做测
第二个我要提的是程序开发的能力.有人会很好奇,为何QA需要懂开发呢?其实不然,对于你要测试的东西,你怎么能不懂它怎么做出来的呢?若是你能懂软件开发,你会有以下好处:1.你可以用RD听得懂的话,来跟RD沟通.不会让RD你在是讲哪国的外星文2.你可以挑战RD的设计,毕竟多点人一起思考,一定比一个人周密.3.你可以分析debuglog,dump和对照sourcecodes,便可以帮助RD找出可能的roo
每次在面试QA时,很多人都不知道QA是什么,它需要什么样的能力.所以每次我都要很多时间来一一解释.其实这也不能怪面试者,软件测试本来在台湾就不是显学,学校根本就不会教,并且说不定连软件工程的课都没有开,所以大家都不会.其实这另一方面也显示了台湾软件界落后,大多人只知道软件开发里,只有写程序和项目经理两种角色,事实上台湾业界大多也只有这两种.让我们回归正题,首先,对于QA所要具备的能力,我第一要提当
单元测试=白箱测试?这是很多人的想法.一听到白箱测试,就认为他就是单元测试.或者认为单元测试时,就是要用白箱测试的方法来进行.事情是这样吗?让我们继续看下去:当我们要测试这个程序时Stackpush(Stacks,intkey)你会怎么测试呢?你可能会考虑以下几种状况(1)空的stack,第一次push(2)不是空的stack,然后push东西(3)stack是满的,push个东西看会不会有问题(
在敏捷开发中,我们都知道要将功能切割,每次做些小功能,然后持续交付价值给客户.因此当你在开发每个小功能时,你会不断进行以下事情:1.从主干checkout程序代码到分支2.开发团队在分支进行开发3.小功能开发完后,将分支程序,merge回主干4.在主干进行测试可是通常这样在第四步时,就会遇到一堆错误.这是因为小功能还没确认是否正确,就和整个系统和起来测试,将导致问题多多.如果有很多小功能要放进来时
每次新版本要出货时,常常被询问是否测试结束了?质量是否有信心?你依据的标准是甚么?我想很多人都会觉得很难回答这个问题.基本上,可以根据以下五种状况,来决定是否测试可以结束.1.老板说了算基本上,老板是无敌的.他说甚么时候就是甚么时候.我想大家不会,也不敢不同意.XD2.团队有共识要停止如果团队讨论完后,决定要何时停止测试,这样也是可以结束3.当代价太高如果要找到下一个bug的代价,会超过这个bug
软件测试的方法有很多种,其中黑箱测试方法被使用最多,主要的原因是容易上手,进入门坎不高.所以很多测试人员会使用这种方法.可是很多人对于何时该使用却不是很清楚,因此让我们来做个简单的比较吧1.ECT(EquivalenceClassTesting)a.说明:将受测软件的输入数据,切成好几个分割(partitions),对于每个分割,将会有测试个案去涵盖它b.适用时机比较小的功能,或是单一API.或是
热门文章