每一段时间,就会有人开始讨论QA的performance要如何评量,有些人会提出以下的index-计算所找到的Bug个数-在一段时间内所开立的测试个案-所执行的测试个案个数-自动化测试个案个数/所有测试个案个数-测试涵盖度这些index的缺点,是缺乏考虑整个环境或是项目的状况,容易会忽略一些会影响的变量.作者认为如果没有根据context就来衡量个人的绩效,是一件愚蠢的事情.例如有些狡猾的测试人员
在我们团队中,我常听到一种抱怨,就是designspec写的很差,或者是很晚才拿到它们.这是因为在微软中,PM是负责撰写详细的spec,RD则是来实作它们,而tester则是用它来开立测试个案.因此你可以想象在这种模式下,如果spec没有产生,tester会非常惨,因为他扪根本无法知道feature在做些什么.不要误会我的意思,即使是一个agile的团队它们也需要设计文件来告诉他们一些事情,可以经
作者根据他的经验,整理了一些事情,让你知道它们是一些不好的思维,不要在测试过程中去作它们1.Don’tleaveallthetestingtotheQAdepartment!-这意味着我们需要多做一点unittests,来帮助我们早点发现问题-这样才能让我们能花较少的时间和精力来解决它2.Don’tleavethetestingtotheend!-真的,当你一有什么就开始测试-包括tester一开
在ExploratorySoftwareTestig一书中,JamesWhittaker在第二章中,提到各种测试方法的不足:DefectPreventation从开发人员的角度来说,他们希望藉由designreview,codereview,staticanalysistool,和unittest,来增加软件的质量.但是作者觉得这些方法都有些根本的问题:(1)开发人员通常不是个好的测试人员-开发人
作者在这篇文章中,列出了七个项目,指出怎样的开发人员,才是测试人员心中的好的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所要具备的能力,我第一要提当
热门文章