一个好的QA在于他的心态(mindset)是否正确,但是心态这种东西是很难加以衡量的.因此很多manager都是以数字来衡量绩效好不好.像是bug数,testcase数,或是有多少被automate.可是我想数字这东西常常会造成一些副作用,因为你只会看到数字,而不会去想他背后的涵义,或者是要因应目前状况做去适当的调整.所以作者认为与其考虑数字,不如考虑下面事情Howmuchbetterateste
通常TestManager会利用下面index,来评量QA是否做的很好NoofTestcasesprepared:1230NoofTestcasesExecuted:345NoofTestcasesFailed:50NoofBugsreported:59NoofRequirementsAnalyzed:45Noofrequirementsupdated:50NoofTransactionscove
在面试QA时,你会苦于不知道要问什么问题,来确认是否有testing的经验吗?这里作者提供了50个Q&A,让你可以彻底了解candidate会些什么.虽然答案部分我不是很满意,但是还是可以参考一下.http://software-testing-zone.blogspot.com/2007/01/top-50-sofware-testingsqa-faqs-you-may.html当然这些
这个问题,我想是大多数公司或是QAmanager的梦靥.一方面找不到好人才,一方面人才也不易留住.很容易地,QA不是离职就是换跑道到RD去.让我们来看看Microsoft资深的QAmanager如何看待这个问题.在某一场合,作者被问到一个问题:你如何保持在QA这条路上,而不会想转换到RD去呢?他说他已经听过很多次这样的问题.许多人把QA视为是RD的一个跳板,一个先期训练中心.他说如果是这样也不错,
哟哪桑在他blog中,有post一篇文章"FeatureRequest,OrBugFixing?"其中谈到一个长久以来争辩不休的问题:当你找到一个问题,你会视为bug,还是视为feature?当哟哪桑一发表完后,已起很大的回响,很多人提出不同的看法.我想是很值得大家去看看最近小弟在闲逛时,刚有看到相关的blog文,因此找出来让大家参考一下另一种说法.Bugv.s.Feature
对于在软件测试上的职涯规划,作者非常主动地鞭策自己一直往前进.他认为不管公司有没有提供这样的协助或是规划,自己都有责任对自己专业生涯发展做些事情.他发现IanClatworthy提出了一个professionaldevelopmentframework,M.E.T.A.-Management,Engineering,TechnologyandApplications.他根据这个framework加
1.要记得鼓励你的员工2.要找寻资深的经理当你的导师3.要把RD当作是你的客户4.要订定你测试方向或策略,并且取得相关stakeholder的共识5.选择你需要的metrics来管理测试的状况,但不要过度迷信它6.要能善用工具帮你自动化,但要确认它真的能帮上忙.7.要能度量你的测试是否真的很有效率8.要持续投资来赶上你的测试环境9.记得要在CCB(ChangeControlBoard)中出席或是有
在几个月前,我请我11岁的儿子帮我在家里做一些事情.过了一段时间,他开始做一些我没交代他做的事情.我告诉她:"你没有在帮我忙"我儿子说:"但是我正在帮你耶!!""不,你不没有在帮我""我在帮你忙啊!!我真的在帮你啊!!"他大声叫喊着.他感到非常挫折.他真的以为他是帮我,可是他并没帮到我.我也感到非常挫折.从我的观点,他
什么时候已经测够了,可以停止了,这个问题是QA常常会被问到的,也是其中一个不容易回答的问题.可是这也是你无法逃避的问题,因为每次product要release时,你就要面对一次,即使没有人问你,你自己也会问自己是不是可以出货了.以下是常见的的criteria1.Allthehighprioritybugsarefixed.-这通常是最重要的,如果重要的bug没解,是不敢出货的-不过通常仅限于重要的
在测试现场，有一个关于测试专家使用认证模型及其必要性的生动讨论。测试人员大致可以分为两组:一组是声明当认证时，不会变得更好，因为目前的认证如ISTQB和ISEB注重方法和术语而无法观察到测试者的实际测试技能。一个提前认证过的小组认为测试行业如一个年轻人，缺乏认证模型，而这类模型已经被其他专业人员使用多年。同时，有人说，测试行业在IT行业被接受，已经成长为一个成熟的行业。最近欧洲STAR会议的网站表
热门文章