微软对测试人员有提供以下trainingroadmap0.Day1-2:CrossDisciplineNewEmployeeOrientation1.0-2yearsTestDesignApproachesTestAutomationDebuggingModelBasedTestingElectiveCourses2.2-5yearsTechnicalElectives:Designpattern
作者在这里列出,bugreport常见的一些问题,很值得QA人员注意:1.不完整的reprosteps-95%的人认为bugreport最严重的问题就是reprosteps不完整不详细.-RD,QA会来来回回的确认问题在哪里,将会浪费两边大量的时间-造成此问题容易被放在最后才解,并且也造成双方不信任或是气馁2.出现在像email形式的讨论-不要出现太多废话,毕竟bugreport是一种techre
你要report一个bug时,若是你并不知道rootcause,请确认你会把以下信息放到bugtrackingsystem中:#screenshots#logfiles(localandserverifyoucangetthem)#machinestats(CPUusage,memoryusage,disk,etc…)#whatwashappening:*Whatwereyoudoing(step
要测多少才足够呢?这答案会根据你所问的对象而有所不同.不过其中一个答案,应该会有人回答你要达到100%测试涵盖度.但是也会有人说那不重要,重要的是你应该根据测试结果的质量来决定,测试涵盖度不会告诉你任何有测试结果或是程序代码的质量.来自ObjectMentor的TimOttinger写到:http://blog.objectmentor.com/articles/2007/05/07/unit-t
这里有列出开发人员常去的前100大blog(2009Q1统计的),此外在这里你可以看到excel文件的数据http://nooperation.typepad.com/files/top100devblogsq12009.xls其中和测试有关的blog如下(如果我没选漏的话):TTLTBlog/SiteAuthor/Twitter1925HighScalability(various)2761Ja
昨天老板和我们分享一个想法:除错只能靠DebugLog吗?他说到他来公司已经不少年,可是对于公司的一件事情还是不是很习惯.那就是engineer要解决一个bug时,总是要求说要提供debuglog给他,否则他们就无法解这个问题.对他来说,这事件很不可思议的事.因为解决问题的方法很多,并不是只有看debuglog才能解决,而且这可能是你不肯动脑的借口,只想让人把线所放到你面前.更糟的事,这线索可能是
最近在测试时遭遇到一个问题:当用户在执行我们的产品,同时也在执行其他软件,像是ftp,听音乐,上网,烧片子,用MSOffice,MSN,facebook...等等,可能会造成系统缓慢或是不正常.我们的QA大部分时间都在执行funcationaltesting,也就是确认我们系统的功能是否正确,因此在他们执行过程中不会去执行其他软件,因此也就没有遇到这种状况.或许有些QA会想说要做兼容性测试(com
最近公司在讨论QAmanager到底要做些什么？有哪些挑战是我们目前大家所共同遭遇的？一开始大家讨论就很热烈，但是很快地，答案就收敛下来，因为大家的心中的痛都一样。首先，在工作项目方面我们认为QAmanager有以下项目：1.人员的管理：包含指导(coach)、发展(develop)、生涯规划(careerplanning)等等。2.人员的录用(Hiring)与解雇(firing)3.和公司目标(
目前最有名的是这两本书,RexBlacky在这方面真的十分有经验,他可以写一堆想都想不到的东西,你不得不佩服他经验真的是很丰富.我想若是有志成为QAmanager的人,这两本是一定要看的1.CriticalTestingProcesses:Plan,Prepare,Perform,PerfectbyRexBlackhttp://www.amazon.com/Critical-Testing-Pro
一个好的QA在于他的心态(mindset)是否正确,但是心态这种东西是很难加以衡量的.因此很多manager都是以数字来衡量绩效好不好.像是bug数,testcase数,或是有多少被automate.可是我想数字这东西常常会造成一些副作用,因为你只会看到数字,而不会去想他背后的涵义,或者是要因应目前状况做去适当的调整.所以作者认为与其考虑数字,不如考虑下面事情Howmuchbetterateste
热门文章