软件测试中的经济学

2010年1月18日 抽屉 没有评论

看这篇Blog的名字或许有朋友会想说我在胡说八道吧.

说实话这个名字也是我刚想到的,原因则是Alan Page的一篇Blog “Why bugs don’t get fixed“,作为软件测试人员我相信对于软件的质量总是有那么一点洁癖才行的.

不管多么细小的Bug都要把它找出来才好.

往往在产品临近发布时,还累积了那么多的未修复Bug,很多是优先级2,3,4的吧. 这时候开发经理一般会决定把那些优先级1而且严重程度最高的Bug修复了就可以发布这款软件了.测试人员往往会据理力争”不行!那些Bug都没有被完全修复呢!” 于是为了修复这些Bug却又新加入了n个Bug,这个软件的发布日期一推再推,最后甚至就不了了之了.

这个故事告诉我们其实修复每个Bug都是有机会成本的,这个成本主要表现在 Bug的严重程度(对客户造成的损失程度,严重的损失面临的赔偿也必然是天文数字的) Bug的隐藏深度(到底要经过多少操作,有多少用户会发现这个Bug; 大量用户通过几次点击就发现的Bug显然是有很大的机会得到修复) 加入新Bug的风险(往往Bug都是成堆抱团出现的,在修复玩一个Bug之后,可能会引入更多的Bug) 以及发布的时间(没有足够的时间进行修改候的测试也是具有高风险的). 所以一旦Bug的机会成本大到我们没法接受,那么这个Bug就必须被修复,延迟发布日期也在所不惜.相反的,机会成本越低的Bug得到修复的机会也就越低.

当然,在这几个变量之间,我还想在增加一个变量”延迟修复的时间”,软件的产品在发布之后往往会跨越地域的限制,全球的客户都在使用相同的软件,当经过了足够长的时间之后,少量的对产品的不满会因为”长尾理论”的关系变得明显起来. 对当前版本来讲这个变量不重要,可是对于还在生命周期种的产品来讲却也是一个不能不考虑的变量呢.

好吧,如果哪位朋友愿意就这个话题在继续进行探讨的,可以留言给我.

新学到的一个词SME

2009年9月30日 抽屉 没有评论

今天在读“How we test software at Microsoft“时遇到一个词之间没有接触过。“Subject Matter Expert” 简称SME(发音S-M-E 或者 smee)。

从字面理解,这个词指的是“主题事务专家”,不过单纯的看这个单词还是不明白到底是什么意思。于是祭出Wikipeidia大神:

A Subject Matter Expert (SME) is a person who is an expert in a particular area. In software engineering environments, the term is used to describe professionals with expertise in the field of application but without technical project knowledge.

The term “SME” also has a broader definition in engineering and high tech as one who has the greatest expertise in a technical topic. SMEs are often asked to review, improve, and approve technical work; to guide others; and to teach. According to Six Sigma, a Subject Matter Expert “exhibits the highest level of expertise in performing a specialized job, task, or skill.”[1]

When spoken, sometimes the acronym “SME” is spelled out (“S-M-E”) and other times voiced as a word (“smee”).[citation needed]

In software development, as in the development of “complex computer systems” (e.g., artificial intelligence, expert systems, control, simulation, or business software) an SME is a person who is knowledgeable about the domain being represented (but often not knowledgeable about the programming technology used to represent it in the system). The SME tells the software developers what needs to be done by the computer system, and how the SME intends to use it. The SME may interact directly with the system, possibly through a simplified interface, or may codify domain knowledge for use by knowledge engineers or ontologists. An SME is also involved in validating the resulting system. SME has formal meaning in certain contexts such as CMMs.

Certification tests are often created by a team of psychometricians and a team of subject matter experts. The psychometricians understand how to engineer a test while the subject matter experts understand the actual content of the exam.

Technical writers and instructional designers typically use the term SME to describe any individual with expertise in the subject matter. Technical communicators interview SMEs to extract information and convert it into a form suitable for the audience. SMEs are often required to sign off on the documents or training developed, checking it for accuracy.

好吧在贴过这么两大段的英文之后,总算对这个SME有了一点了解。SME简单的说,就是一个对某个领域的事务非常了解的专家。在软件开发过程中,他可以提供自己的意见,但是他不需要具备专业的编程技巧。

不过,很奇怪,为什么Alan Page为什么会说“A common question that comes up during industry events is why Microsoft doesn’t hire subject matter experts (SMEs) as testers.” 因为在我看来排除微软要求的测试人员是Software developer engineer in test(SDET) 这样需要一定开发经验的,就算是单纯的黑盒测试Tester 也与SME有着区别的。测试人员要求具备的测试技巧与SME只是在某一方面的专家水平是不同的,这么说吧,测试人员在具备了很多测试经验之后,可能达到SME的水平。而一个SME却也必须先要了解这么去发现问题 :-)

不知道我的理解对不对。还请看到的老师们提供宝贵意见。

沙盒测试,与星璇探讨

2009年3月10日 抽屉 1 条评论

在淘宝的QA团队Blog上看到一篇对“沙盒测试”一词的疑惑。星璇说:

看了上述的解释,依然没有很明白的搞懂,沙盒测试这个概念,是和我们一直接触的白盒测试和黑盒测试类似的软件测试的一种方法吗?

之前,光知道“沙盒测试”这个名字,对于到底什么是沙盒测试,沙盒测试和传统的白盒测试,黑盒测试到底有什么区别却不甚了了。很惭愧。

趁这个机会,上网搜索了一下“沙盒测试”这个关键词,还真的没什么特别有用的信息,奇怪了。大多数的结果指向的都是Wiki的“Sandbox”页面…既然这样,索性就上Wikipedia看看吧。

总算,Wikipedia上找到了一个条目Sandbox (software development)这个应该就是我们所需要的答案了。

A sandbox is a testing (or virtual) environment that isolates untested code changes and outright experimentation from the production environment or repository, in the context of software development including web development and revision control, and by extension in web-based editing environments including wikis.

具体的解释如上,沙盒本身是一个虚拟的测试环境,它把未经测试的代码变化与实际的产品环境隔离开来。沙盒用在包括Web开发和版本控制在内的软件开发过程中,当然,在基于Web的编辑环境比如Wiki中也非常常用。

沙盒测试的概念不同于一般的“黑盒”“白盒”测试的概念,他是一整套测试的环境。个人觉得,有点接近于黑盒测试,不过更多地运用了版本控制的概念,代码的变化在经过沙盒测试之后,可以签入到正式的产品环境中去。沙盒环境可以被看成是“开发环境”或者是“开发代码”的“测试分支”。

嘿,很有趣,这个词在传统的软件测试流程中几乎不被提及。不知道是什么原因。照理他们也会运用CVS和SVN之类的版本控制工具啊。或者有哪位可以帮我指点一下?

分类: 求甚解 标签: , ,

淘宝的测试团队

2008年12月23日 抽屉 1 条评论

印象中,阿里巴巴的技术团队是一个开放的团队。尤其是UED的团队,阿里巴巴各个子公司的UED团队几乎都有自己的团队Blog。在这些团队Blog之中,尤其出名的,恐怕又要算淘宝的UED团队了。

不过,让我没想到的是,淘宝不光有UED的团队Blog,有DBA的团队Blog,有数据平台团队的Blog,居然还有一个QA团队的Blog。这似乎就连在阿里巴巴也是唯一的一个QA团队的Blog吧。原先,我还在想,QNotes上能更新一些什么东西呢? 在看过淘宝QA团队的Blog之后,才发现,原来QA的Blog可以这么写!

很感谢TaobaoQA team,我坚信技术只有在开放的交流中才会有加速的升华。

分类: 标签:

旧文一则:如何准备软件测试工程师面试

2008年8月4日 抽屉 没有评论

这篇文章是在2006-11月写的。曾经是我Blog上访问量前10的一篇Post,而且在转载的时候被当成是Google工程师写的。

我先说明一下,我不是Google的工程师。在写这篇文章的时候,我在T社工作,这家公司也算是全球500强之一,老牌的IT企业了。

因为这篇文章和软件测试相关,所以就转了过来。当然,因为时间又过了1年多了,所以在我的思想上又有了一些变化。或者有时间的时候我会再写一篇。

++++++++++++++++++++++++++++++++++

差不多又到了每年毕业生找工作的时间了。

最近因为手头的项目一直在招人,对于招聘这个话题还有一些想说的。其实这个事情有不少Blogger都提起过,比如DBA,Laura,甚至在Google中国的黑板报上都有王忻写的一篇如何准备软件工程师的面试。我只能结合我在工作中的一些体会来谈谈在应聘的时候应该注意那些问题。当然,这里所写的,只代表我个人的一些看法,和我所服务的公司择材标准并不完全符合,特此声明。

第一点,守时。
这点很重要,也是一个起码的要求。我碰到过一些应聘者,通知某个时间到公司参加面试,结果迟到了整整两个小时,期间也没有任何电话联系。这给我留下的印象 是这个应聘者对这份工作不是很重视的感觉。虽然现在城市交通非常拥堵,但是如果你和对方约好了面试时间的话,还是早一点出门的比较好。实在无法在规定时间 内赶到的,也要打个电话说明情况,免得对方干等着。

第二点,在确定面试时间和地点的时候,记得互相交换联系方式。
这个,其实和上一点相关。可以在事情出现变化的时候及时联系,这点我想也是比较重要的。

第三点,做好相应的准备。
在面试开始之前,最好能对这次面试做些准备功夫。俗话说:磨刀不误砍柴功。这是有道理的,在面试之前对自己应聘的工作岗位,公司的企业文化等等在 Google上查找一些基本内容,在面试的时候往往能增加不少印象分。起码,我会觉得他是一个肯学习的人。再有一点,正对软件测试工程师这个岗位,一般会 有笔试,请记得准备一支顺手的笔。这也是一个小细节,我觉得这是一个人对待工作的态度,是否考虑周到的表现。

第三点,请看清笔试问题。
如果面试之前需要笔试。请不要紧张,仔细看清问题。不要拿起笔就瞎答一气,这不是大学里的考试,这只是应聘工作中的一个环节而已 ;-) 有的同学在笔试的时候为了让试卷看上去都填满了,所以看到空格就往里填。这个不可取 ;-)
第四点,请真实面对自己的能力。
不要谦虚,但也不要夸大。面试不是孔融让梨,当问到你的能力时不用太谦虚,要不然会显得不自信。当然,也不要太夸大自己的实力。
谦虚的人比较少见,但是夸大的人近段时间的面试中比较常见。有些应聘者写着对某项技术的掌握程度是精通,可仔细一问,就可以发现原来只是对这项技术有所了解而已。
所以,请牢记以下几个词语的区别:了解,一般,掌握,熟练,精通。 在我的理解里这些词之间是一个递进的关系,而不是同义词。

第五点,礼貌。
这点又是普适性的基础。在进门之后对考官的问候,接受面试时的仪态,以及离开座位时的动作。或许是因为我原来的专业是管理,我会注意到这些细节 ;-) 虽然大家印象中技术人员对这个比较不是很严格要求。
有些面试同学坐在位子上或许是因为紧张,或者双手握拳,或者不自觉地晃动双腿。我建议可以让自己坐在椅子的前1/3处,这样的浅坐可以使身体略微前倾,避免抖动双腿,把双手交握放于大腿上可以防止双手握拳的紧张姿态被面试官看到。
在接受面试的时候,有的同学不注意和面试官的目光交流。在听问题和陈述思路的时候如果能够适时地和面试官做些目光交流会显得有自信的多。
离开座位的时候,大多数同学会记得和面试官致谢。但是却有很多同学忘记把作为放回原位。有始有终才是一种好的工作态度哦。

第六点,紧张固然不可取,闲聊式的面试却也很难让人接受。
有些同学的话语欲望很强,以上来陈述问题就开始如滔滔江水…让人难以打断。这个对我来说是一件比较尴尬的事情。眼看着同学离题万里,却没有办法把他中断下来,浪费了面试的时间。

第七点,衣着。
对于一名软件测试工程师来讲,这一点或许真的不那么重要。
保证衣着整洁,仪态也保持清爽就够了。这点在我遇到的同学中间还算大多数都可以做到的。比较不可取的是穿着好几天没洗的皱巴巴的衣服来面试,或者头发有些乱蓬蓬的,我个人会觉得这样比较匆忙的准备,今后的工作中是不是一样会丢三拉四呢。

顺便在说一个,注意自己的口头禅。每个人都会有一些口头禅,在紧张的时候尤其容易出现口头禅。“嗯,啊”之类的还比较好理解。我遇到过以为面试者, 在很长时间的自我陈述中一直在重复他的一个口头禅:“就是说” 这个词在整个陈述中隔几秒钟就出现一次。我开始变得神经紧张起来,注意力都被“就是说”吸引,对他的陈述内容反而没什么印象了。
在紧张,需要组织思路的时候,可以略作停顿,但不要用太多的口头禅来掩饰,这是我个人的建议。

好拉。这些也是我一时间想到的。如果你还有什么想法的话咱们可以再继续交流

分类: 标签: , ,

看”软件测试与持续质量改进(第二版)”不明白的地方

2008年7月28日 抽屉 没有评论

这几天在看“软件测试与持续质量改进”的第二版。原著是William E. Lewis, Gunasekaran Veerapillai。由陈绍英等翻译,人民邮电出版社出版,2008年2月第一版第一次印刷。

刚开始看,看到”1.15开发和实施软件质量保证计划的步骤“时发现一些不明白的地方。

根据书中的描述:

步骤1:编写计划;步骤2:获得管理层认可;步骤3:获得开发人员认可;步骤4:准备编写SQA计划;步骤5:执行SQA计划。

我的问题是,这步骤1中的”计划“是不是指SQA计划?从下文的描述看,很像。而且从本章的标题看,也应该是。不过,为什么在经过了步骤2和步骤3之后,又出现了步骤4?这几个步骤不是按照从前到后的时间顺序的么?第一个计划和这一个SQA计划有什么区别?看译文我没法完全理解。

我在Google上找英文的原文,没有找到。不知道有谁看到过这个原文的。我想知道是翻译的问题还是我的理解问题?

虽然我知道,做测试不能太教条,但是有时候通过看书把日常的思考条理化倒是非常不错的选择。

分类: 求甚解 标签: , ,

向DBA Notes致敬

2008年7月17日 抽屉 2 条评论

掰着手指算起来,我参加工作也已经有4个年头了。从我毕业到今天,我的工作一直是软件测试。

软件测试这个活,在不同的公司似乎有不同的称呼:QA,QC,Tester,Verification,Evaluation…不过不管名字是什么,工作的内容却差不多。

在日常接触的Blogger中,Fenng的DBA Notes对我印象很深刻。当时很想有一天也可以把自己在工作中的体会写到Blog中来。不过当时一个是因为工作的时间不够长,还有就是工作的环境不是很允许有这样的事情发生。所以直到今天,我才开始动手开这个Blog,希望可以在今后通过这个Blog来跟所有对QA这个工作感兴趣的大家沟通。

所以,这个Blog的第一篇,我就专门用来向Fenng致敬。向他学习。

分类: 碎碎念 标签: , , , , ,

Hello world!

2008年7月15日 抽屉 1 条评论

欢迎来到 I@Log.com. 这是你的第一篇日志. 你可以随便编辑它,甚至删除它,让我们开始Blogging吧.

分类: Uncategorized 标签: