Heuristic是一种经验为主的解决问题之技巧.它可用来快速找到可能的最佳方案.wiki有对他有更多的解释http://en.wikipedia.org/wiki/HeuristicsRobson提出了36个有用的TestingHeuristics,主要可以分成四类:Group1–cidtestd=Customers,Information,Developerrelations,Team,Equ
作者和JamesBach访谈后,收获不少,他整理出要成为一个professionaltester应该要如何做:1.Createyourowndefinitions.-定义什么是你认为好的或是完美"testing"和"quality"-并且检视你所做的事情,那些行为是符合你所定义的-也就是你自己能够建立一个framework,来规范自己想要做的事情,并且能评估
很多测试人员很有兴趣,管理高层是怎么看待测试团队?作者问了一群有资深的测试人员和测试经理,得到以下的答案:Whatisthepoint?NecessaryevilAdhocWhysomuchtime?TooslowOverstaffedToomanyexcusesTestingshouldfindeverythingQualitygatekeeperFindbugstoolateTestingle
每一段时间,就会有人开始讨论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的对应关系.这样你便可以
热门文章