优秀员工的十大要素

前两天整理自己在微软的工作邮箱时候,偶然看到多年以前比尔·盖茨写给员工的一份邮件,我一直保存偶尔翻出来看看。他在该邮件中列出了成为公司优秀员工的10大要素。   经常有人问我如何成为一个好的经理,我在许多专栏中也多次谈到。但是很少有人反问:如何成为一个好的员工? 下面是我在最优秀的员工身上发现的他们共有的10大特征,公司应该竭尽所能吸引具有这些特征的员工。 如果你具有这些特征,你可能就是这些最好员工中的一个了。 第一:你必须对你的产品有强烈的好奇心。你必须亲自使用你做的产品。这一点非常重要,不仅在计算机世界里,在其他高速发展的科技行业也是一样。如果你对自己的产品不热情,你很快就会被淘汰了。 第二:你必须擅长和客户讨论他们是如何使用你的产品的,他们喜欢什么,不喜欢什么。你需要不停宣传你的产品同时很现实地清楚知道你的产品中的不足和需要提高的方面。 第三:一旦理解了客户需求,你必须很乐意地去思考该产品中如何帮助客户。比如,如果你是开发软件的,你可以问自己我的产品如何让用户更享受工作,如何让用户更乐于学习,如何让用户在家里更乐于使用?   前面三点彼此关联。成功来自于你理解和对产品,使用的技术和用户的需求的深深关注。   第四:做为员工中的一员,你应该保持和公司一样的长远策略。员工需要专注于自己一生的目标,比如发展自己的能力。这种动力需要很强的自律但是会有好的回报。当然管理层也应该鼓励这种自我激励。比如如果你是销售,每月的销售量是很好的考核标准。当销售量超过预期是很好,但是如果超过预期销售量是你唯一的动力,你可能会错过类如团队合作和发展等有助于长期成功的方面。 第五:你必须在某个方面有特别的专长同时又有广博的知识。特别是大公司需要可以快速学习的员工。没人可以保证今天的特长明天还管用。所以必须好学。  第六:你必须灵活利用给你的机会。微软为每个员工提供多种不同类型的工作。我们鼓励对管理感兴趣的员工在不同领域理工作,即使需要不停换工作。 第七:好的员工想学习一些经济商业知识。你的公司为什么要做这个产品?业务模式是什么?如何赚钱的?很奇怪有些公司不告诉员工这些东西。员工需要明白业界的成功与失败,这样她才会明白他们的价值所在。  第八:你必须关注你的竞争对手。我很喜欢哪些留意市场动态的员工。我们的竞争对手聪明在哪里?从他们哪里学什么?如何避免他们犯的错误? 第九:你必须思考。分析问题但是不可以一直在分析。了解各种可能的折衷以及他们的影响。比如是有一点信息后就快速行动呢?还是等待更多信息后在行动呢?学会在两者间的折衷。现实考虑问题,有效利用时间,考虑如何给别人清晰的意见。  最后:不要忽略那些明显的特征比如诚实,守信,努力。这些特征不用说至关重要。      

2

提高软件质量实践―― Facebook 篇

Facebook从04年的哈佛校园的学生项目在短短的7-8年的时间中快速增长为拥有10亿用户的世界上最大的社交网络,又一次见证了互联网创业成功的奇迹。同时它的产品研发流程也成为了众多互联网产品公司的追逐对象。今天我们来看一下facebook在产品质量控制方面的实践。有人说,现在的google象早期的微软,现在的facebook象早期的Google. 我觉得无不道理。 虽然facebook已经早已不是创业公司,但是不难看出它在产品研发和质量控制仍然保持着创业公司的风格。在产品研发上,他们以小的研发团队为核心,遵循几个非常重要的原则: Be there from start to ship: 每个工程师自始至终负责产品。从最开始的一个想法,到开发原型,到内部审核,反馈,到产品开发,上线和维护,全部有工程师自己搞定。 Show work early and often:  facebook非常看重反馈,尤其早期内部反馈。他们鼓励工程师有了想法后,尽快开发出原型,尽快得到反馈。 Gets your hands dirty: 动手去做,去实现。 Don’t fall in love: 互联网产品是不断变化的,不需要等到把一个产品设计的很完美了才发布。   为了遵循以上原则,facebook工程师采用以下质量控制手段来保证产品质量: 开发对质量负责: 开发从设计,实现,测试,到部署都要自己做。其它做工具,流程的工程师通过开发工具和流程来帮助开发人员更为简单方便地做测试,做部署和做监控。每个开发人员有自己单独的测试环境,测试环境就是运行在开发本地机器上,部署非常简单快速。测试环境用的是真实的用户数据。 持续集成和测试自动化:每周发布一次。星期天晚上,要发布的构建从主线上分支出来到发布分支,到星期二的中午如果没有大的问题,就可以上线了。所有的测试运行控制在10分钟以内,所以不需要考虑不运行哪些测试用例。运行所有测试用例。 (只是听说,没有经过考证。) 内测 (dog food):发布之前,公司员工使用要发布的功能。2-3天之内可以有几百个或上千个人在使用新功能。负责要发布功能的开发人员在星期天晚上到星期二中午之间会做大量的测试 (一边上班,一边刷微博,岂不是很爽 )。 发布风险控制:新功能本身质量可能有问题,新功能也可能影响其它现有功能。为了减少或控制这些风险。Facebook开发了一整套完善的发布,控制,监控流程和工具。做到:1.测试通过后,产品质量基本有保证。2.即使有漏测的bug,只会影响很少量的用户。3.及时监控到问题。4.及时修复。 产品监控:监控产品的系统的运行状态。    Facebook之所以采取这种质量控制策略和它的产品特点密切相关: 用户对社交产品质量的容忍度相对较高。比如发微博,现在连不上,等一会在连接也可以,现在发布不出去可以等一会再发,粉丝数量统计有误,没有人太关心。其实facebook并不认为自己的质量差。他们认为产品的质量高低不是有多少个failed测试用例,有多少个bug来确定的,而是有用户对质量的期望值来决定的。如果用户对产品质量的期望值很高很高,一个bug漏掉了都会照成质量差的印象,用户很有可能放弃使用。相反,如果用户的期望值一般,100个bug漏掉了都不会影响用户继续使用。所以facebook产品发布的条件是满足用户对质量的期望值即可。 相对宽松的产品发布周期。不想微软或google很多产品已经在市场上,用户对下一版本的发布时间和新增加功能的期望很高,这往往给产品开发组的压力很大。Facebook基本没有这个问题,它有适合自己的发布期限,不用受到外界干扰。 产品发布和监控流程比较完善,即使有漏测的bug,对用户的影响可以控制在最小而且可以及时发现及时修复。   Facebook质量控制中引以为豪而且倍受瞩目的就是“没有专职测试工程师”。我这里需要专门讨论一下: 什么是“专职测试工程师”? 头衔里面有“测试”的工程师?专门找bug的工程师?专门做质量控制的工程师?等等。 Facebook的确没有带“测试”头衔的工程师,也没有专门运行产品找bug的工程师。每个人都是开发工程师。但是他们的实际工作有区别,有的专门做面对用户的产品,有的专门做测试,开发工具,有的专门做产品的构建和持续集成工具和流程,有的专门做发布和监控的工具和流程。如果按照传统意义上的开发和测试的划分的话,除了第一类外,其他都可以看做专职测试工程师。 Facebook不是惟一一个没有带“测试”头衔工程师的公司,很多软件公司都没有,比如twitter. 很多人把专职测试工程师指专门运行产品找bug的工程师。微软在2005年去掉STE (software test engineer )岗位,就已经没有这一类型的专职测试工程师了。…

2

Dev owns testing, Dev owns quality, really?

You might hear a lot about dev owns quality recently. James whittaker, the former engineering director of Google, spends quite a lot pages in his new book <<how Google Test software>>  to articulate why dev should own testing, and why should dev owns quality, like this: “Who better to do all that testing than the…

3

提高软件质量实践―― Amazon 篇

前几天回国转了一圈,做了两家企业质量管理培训,一次上海测试沙龙,和chinatest两次演讲。收获颇多,以后慢慢分享。回来后发现我的软件质量实践系列文章距离上一次发表已经有很长一段时间了。我想还是先把它写完,再写别的文章吧。那么今天我们看看互联网公司的另外一个大哥大是如何做质量控制的――Amazon. Amazon是一个很传奇的公司,它1995年的时候以一个网上书店起家,在短短的十几年里成为全球最大的在线购物公司。更为甚者,他在2005推出的AWS云计算服务更是被业界公认为云计算的鼻祖,也是现在全球最大最成功的云计算服务提供商。我一直坚信成功的产品一定是由成功的质量控制做保障的,采取什么样的测试策略只有两个决定因素。一是企业文化,二是产品特点。在分析Amazon的测试策略之前,我们先看看它的企业文化。 业界关于amazon企业文化和成功要素有很多,我觉得实际上最为核心的只有一个,就是他们的“low margin, large volume”理念。就是通过单个商品的低利润和巨大的销售量来最终提高公司利润和公司业务向前发展。工程团队的理念就是要保障企业文化得以顺利实施,所以Amazon的工程团队的理念就是如何保障公司“low margin, large volume”的企业文化。Amazon工程团队有以下特点: 独立的团队:在Amazon,负责产品功能模块的每个团队相对独立。他们对该模块的所有功能,性能,开发,质量,上线,维护等从头到尾的绝对负责。我们在Google中也可以明显看的这一特征. 敏捷的团队:为了保障团队的敏捷,Amazon采用“2个比萨饼”的原则来看控制一个团队的大小。也就是2个比萨饼就可以吃饱(5-7个人)的大小。团队内部和团队之间尽量减少工作的交接,一方面减少因为交接照成的不必要延迟,另一方面避免互相推卸责任。Amazon是最早采用敏捷开发(scrum)的公司之一,他们现在绝大多说产品组都是用scrum,据说有超过400多个CSM. 面向服务的产品体系架构。在01年的时候,Amazon随着它的产品线迅速扩大,业务逻辑越来越复杂,现有的产品体系架构极大地限制了整个公司的高速发展。他们重新设计了基于面向服务的,松耦合体系架构,使得各个模块独立开发,修改和维护。所以Amazon可以在不牺牲质量的同时,快速推出新产品新服务。  很遗憾的是Amazon很少公开谈论他们的质量管理流程和策略,不过通过有限的资料,还是不难看出他们的质量管理的策略:  开发对质量负责:因为每个团队对模块完全负责,并且要做到敏捷。Amazon要求开发对质量负责:从设计,写代码开始一直到代码上线。开发做测试不仅可以尽快地发现bug,而且可以避免过分依赖测试人来提高质量,更为重要的优点是开发在设计是会考虑代码的可测试性 (因为他们自己要测试,肯定想方设法使得测试更为容易些),从而使得模块容易测试,容易维护,松耦合,最终极大提高模块质量。因为开发做了大量的测试,Amazon专职测试工程师也比较稀少(据说对开发的比例是1:7左右)。测试的主要职责是负责复杂用户环境下的测试,以及开发测试工具,流程和基础设施。而且很多产品组把一部分功能测试外包,所以即使Amazon的测试工程师不多,但是整个产品的测试工作却没有一点减少。  自动化测试:这里我就不在多说了,和microsoft, google一样,他们开发了大量的测试工具和流程基础设施来提高测试效率。开发专注于写代码和测试,不用在搭建环境,部署,运行测试用例,和反馈上浪费时间。除了测试自动化外,他们也开发了一整套用以产品上线,维护和监控的工具和流程。只有这样,开发才有可能既要写代码,又要对代码质量从头到尾负责。  数据驱动的决策流程:和google一样,Amazon全方位监控它的应用服务的运行状态,从每个API调用时间,到用户使用产品的每一步骤。根据对这些数据的分析和挖掘,开发团队决定如何提高产品质量。    如果大家熟悉Google的软件质量实践应该可以发现,Amazon和google在软件质量控制的理念和实践有非常的相似之处。有所不同的是,google的很多项目以实验性为目的,最初没有任何专职测试。只有等到项目真的被重视后,测试才开始介入。做为互联网产品的两个大哥大,他们的测试方式或许可以代表着互联网产品的测试发展方向吧。下一次我们介绍最后一个公司的测试策略-facebook。  

1

再看云计算是否安全

Amazon的AWS云计算服务又宕机了,这是6月份的第二次。和其它的宕机事件一样,又引发了大家对云计算安全性的质疑。其它的云计算服务比如windows azure 或google的gmail服务的宕机也时有发生。 老是出问题好像不太符合云计算的吹捧的高安全性呀。那么云计算的安全性到底如何,做为那些正在准备引入云计算的公司,是否需要需要再考虑考虑呢?下面谈谈我的看法。 首先要订正的是该事件实际上不属于安全性的范畴而是高可用性的问题。安全性通常是指是否可以访问未授权的资源或数据(当然DoS攻击也是安全性问题),这里所指的是用户部署在云里的服务是否可以一直可用。 所以真正的问题是云计算是否高可用? 在回答该问题前我们需要分清楚云计算里的两个基本概念:计算服务和存储服务。 计算服务是指云计算提供商提供给用户的用以进行运算的服务。它通常是以实例单元来衡量的,比如一个虚拟机可以是一个实例单元。用户在购买或使用计算服务时可以是一个或多个实例单元。比如用户的在线购物应用程序,一个实例单元可以扛得住1000用户的访问量的话,如果你通常会有10000个用户同时访问的话,你至少需要10个运算实例。如果在高峰值时有50000个用户同时访问,你需要购买50个运算实例。而在低峰期是如果只有2000个用户访问的话,你可以只购买2个运算实例就可以了。所以你可以方便灵活地更具用户访问量来调整购买实例的数据量,这样既不会浪费,也不会不足。这就是我们所说的云计算的最大优点之一:弹性伸缩,按需使用和按使用付费。但是,要做到这一点,每个运算实例必须是”无状态”的,也就是每个运算实例完全相同,不可以在运算实例的本地机器上保存任何状态数据。原因很简单:如果你在本地保存数据的话,只有你自己实例能够使用。在前面10000个用户访问量的例子中,在增加再多的运算实例也没有帮助,因为只有你有数据,别的再多机器也帮不上忙。 但是在实际的应用程序中我们又必须处理和保存数据。所以为了运算实例”无状态”而又可用保存数据,云计算提供商必须提供第二个服务:存储服务。 存储服务很简单就是给用户保存数据用的。但是数据是用户业务的核心中的核心,绝不可以出现任何差错。所以存储服务必须使用足够的措施来保证数据的万无一失。绝大多数的公司都采用两中方式:一是:把用户数据划分成块,每一块是一个存储单元。每个存储单元分多次保存在多个服务器上。这有两个好处:一是如果一个服务器宕机了,其它服务器上的数据还可用;另一个是负载均衡以提高读数据的效率。这些服务器都在同一个数据中心,所以使用同步复制,即使把同一个数据块写多次也不会影响写数据的效率。但是把同一个数据的多个拷贝存放在同一个数据中心无法应付大的灾难,比如数据中心失火,地震或城市断电等。所以大部分公司把数据再一次复制保存到另外一个城市的数据中心里(两个数据中心最少相距150公里)。如果一个数据中心瘫痪,可以把用户请求切换到另外一个数据中心。因为两个数据中心的数据复制较慢,所以通常采用异步复制的方式,每隔10分钟复制一次。另外一点是第一种同步复制是默认的,用户不用做任何配置,也是免费的;但是第二个异步复制需要用户提出,而且可能有额外的费用。 所以有了存储服务后,用户就可以把数据或状态保存到存储服务理,而实现运算实例的无状态了。可以随时增加或减少实例数量,一个实例宕机也没有问题,还有其它实例在处理。实际上在数据中心里机器宕机,网络断掉,硬盘坏掉每天都在发生,但是用户感觉不到。如果用户把自己的应用服务同时部署到多个数据中心的话,即使一个整个数据中心宕掉的话,用户的访问请求可以快速切换到另外一个数据中心,用户也不会感觉到任何问题。这就是运算服务的高可用性:服务器宕掉了没有问题,整个数据中心宕掉了,同样没有问题。但是我们可以看的要做到这一点,用户必须做两件事情:1.你必须有最少两个运算实例,道理很简单:如果只有一个,它宕掉的话没有其它实例,当然做不到高可用性。2.你的应用程序必须在多个数据中心部署,一样的道理。最少两个才可以做到双保险。 我们再来看看亚马逊的本次宕机事件。因为当地暴风雨导致数据中心断电,在切换到备用电源后,备用电源出现故障。所以导致整个数据中心宕掉了。在切换到其它数据中心的时候有发现切换程序出现故障,导致无法切换,所以最终导致用户应用服务不可用。另外它都只是计算服务宕掉了,并没有影响数据服务,或则数据没有丢失。等到计算服务回复后,系统恢复正常。所以计算服务宕机很正常,如果数据丢失麻烦就大了。其实这一次恶劣天气照成数据中心断电本来可以体现亚马逊云计算高可用性的一个经典案例,但是很可惜的是它的切换程序出了问题,反而成了失败案例。 所以我们可以看出在保证应用程序的高可用性和数据的安全性上,没有一家单个公司可以做到像亚马逊,微软或其它云计算提供商那样的完备,根本不是一个级别上的比较。我们对亚马逊宕机反应强烈只不过是我们对云计算有着不切实际的期望(100%高可用性)。殊不知我们对自己公司办公室的服务器经常宕机习以为常了。 当然云计算提供商在保证高可用上还要继续努力,但是它也不应该是质疑或反对云计算的理由。另外一点就是要高可用性不是与生俱来的,而是要求用户必须做很好的设计,充分利用云计算提供的机制,而不是把应用程序扔到云里面就万事大吉了。一个最简单的道理:不要把所有鸡蛋放在一个篮子里。    

0

敏捷,是灵丹妙药还是又一个忽悠?

敏捷开发和敏捷测试这两年自从从国外引进后,在国内很火,很多人都在谈论。无论是项目延期,失败,质量低下等等,你总能听到分析的原因是:“看看,你没有敏捷了吧”。所以一下子敏捷成了包治百病的灵丹妙药。很多项目组公司开始学习敏捷,采用敏捷,转向敏捷。但是遗憾的是很多人尝试过后发现以前的问题并没有被敏捷所解决掉,反而带来了很多新的问题,于是也有人就得出结论:敏捷又是一个大忽悠。读了很多网上关于敏捷的辩论,我想起一个故事: 话说清朝的时候慈禧太后听说西方国家有个新的交通工具,汽车,它坐在舒服跑的很快。于是就叫人买了一辆回来。但是用的时候没有人会开,于是不得不把汽车用几根柱子绑起来做成了轿子,让几个人抬着。因为汽车太沉,几个轿夫步履蹒跚,走不了几步就得歇歇。结果以前半个时辰的路走了好几个时辰。而且到了后因为门很窄,汽车做的轿子过不去,她也不得不老远就下来自己走一段。慈禧太后很不高兴就得出结论: 汽车前期投入大,维护成本高。 没有轿子走的快。 很多地方汽车都不适用。 汽车是个大忽悠的东西,根本不管用。 那么我们现在对敏捷的认识是不是和慈禧对汽车的认识类似呢?是因为我们不会用敏捷呢,还是因为敏捷就是个忽悠? 在国外通常一个概念出来之前已经有很多年的实践积累,然后为了大家交流方便或者提高普及度给其一个名字。所以是先有实践,再有概念。但是在国内正好相反,我们先把国外“先进“的概念引进来了而把产生概念的多年实践忽略掉了。但是概念又太虚不能当饭吃,最终还是需要具体东西和具体做法。所以不得不根据概念来设计出各种各样的做法来。这些做法听起来不错,非常符合概念,但是在项目中一使用就不灵了,旧的问题没有解决,新的问题一大堆。最终得出汽车是个大忽悠的结论。 敏捷和云计算是两个非常典型的例子。很多人为了敏捷,文档不要了,计划不要了,测试用例也不要了,认为几个人站在走廊里沟通沟通就把一切都搞定了,因为敏捷了嘛。但是问题并没有因为“敏捷“了而被解决掉,于是乎得出敏捷是个忽悠的结论。云计算也一样,很多人认为云计算就是数据中心,所以大家大兴土木建立数据中心。但是建完数据中心以后呢?没啥用处呀。那大家都在吹捧云计算,不就是个大忽悠吗。 殊不知,人家是因为业务需要很多年了已有数据中心,为了提高数据中心的使用率,开始对公众开放资源,所以才有了云计算。 先有概念再造实践的做法违背了事物发展规律,不仅解决不了现有问题,而且带来新的问题。敏捷是个好东西,在特定情况下。我们需要搞明白的是它要解决什么问题的?它是如何解决的。而不要在乎它叫什么名字或则防止生搬硬套。还有越是先进的东西对人和基础设施的要求越高。比如飞机再好,没有飞行员或则没有机场也没有用。高铁跑的越快对铁道的要求越高。 软件测试也是一样,做质量控制不是为了赶时髦。如果你的项目只做3个月就彻底结束了,而且就3-5个人,不会有人离开也不会有人进来,也不需要和其它任何项目打交道,或则你的产品在早期实验阶段,你可以不要文档,不要计划,不要记录bug,完全靠口头交流。否则的话: 不能没有文档:  但是要减少不必要的文档,避免过于详细的文档,使用易于更新和维护的动态文档。 不能没有计划: 距离现在越远计划越模糊,但是距离现在越近计划越详细。 不能没有纪律:     与其在琢磨如何敏捷测试,不如一步一步把自动化做好,把持续集成做起来,创建更多的测试工具以提高测试效率,把质量反馈系统做起来,把dev提交代码前的质量检查做起来,把在产品中测试做起来, 把测试工程师的素质提高上去,。。。。 等到这些都建立起来了后,你发现自己其实已经很敏捷了。 ————— 关注我:新浪微博:@billliu_seattle http://www.weibo.com/windowsazure 或twitter: @billliu_seattle  

1

google testing 的光环正在褪去?

最近因为在写一个各个公司质量控制实践对比的系列文章,包括微软,google,amzon和facebook,所以对google的测试越加了解。google是互联网公司的领导者,它的产品质量控制也成为其它公司的学习的楷模。James,前google测试总监,在他的新书《how google test software》中号称google的测试实践将会是其它互联网公司实施质量控制的教科书。但是随着对google测试的了解加深,与更多的熟悉或者工作在google的测试工程师的深入交谈,发现google真正的测试实践好像不太完全象外面宣传的那样耀眼。 昨天请了一个在facebook的做网站性能测试的大牛来给我们分享facebook做性能测试的经验。她在google做了5年的测试在2年前跳到facebook。在提到其它公司在推崇google的测试实践时,她把google的测试狠狠抨击了一番。她说google的广告做的很好,很多google演讲的数据,比如每天有多少个build;一个build有多么快速,测试运行有多快速,等等数据有过分夸张。可能某一个组的某些测试做的还可以,但绝不是代表整个公司,甚至不能代表大部分组,至少她在google工作的5年里没有看见过。而且很多内部工具真正的做法,实际效果都不像外面传说的那样神奇。 James 在3月份离开google回到微软。虽然他在博客中强调他离开的原因是不同意google的产品策略以及公司文化的变化,但是我觉得他的根本原因还是他对测试的的看法和公司高层有不小的分歧。而且从他最近写的有关软件后期测试的文章可以很明显地感觉到。James 和其它两个工程师合写新书。书还没有出版,两个作者就先后离开了google,另外一个早就转成了开发。即使在他的新书中,James在最后展望google的测试的章节中,他就承认因为google的测试工程师是用租借的方式分配到产品组中,这使得测试工程师对产品没有归属感。这很令人担忧。很典型的例子:if you ask a dev what she is doing in google, she will say i’m working for chrome, search, g+, etc.. whatever component/product she is working on. however, if you ask a tester what she is doing in google, she will say i’m a tester. 前两天和两个在google测试的工程师聊天,他们也是一直在摇头。而且承认搞测试还是在微软(这两个工程师都在微软工作过)。 google测试实践真的值得推崇吗? 是不是因为google成功了我们就默认为他的所有做法都值得追随?…

1

提高软件质量实践――google 篇

很多人应该都看过James whittaker的博客或新书 《how google test software》,在这里我不想重复他的内容,而是从另外一个角度来分析对比google是如何保障它的产品质量的。  首先申明的是本人并没有在google工作过所以没有第一手的经验,仅以一个旁观者的身份来分析google的质量控制实践。主要信息来源于google测试博客,在西雅图google工作的朋友聊天和项目上合作,以及James的新书<<how google tests software>>。不过旁观者有旁观的优势,可以看见整个森林;相比较许多在大公司工作的工程师往往专注于一个产品或者一个团队,只看见了一颗树木J。不管如何,个人观点仅供参考。  我们前面在微软的质量控制实践中谈到,因为微软大部分的产品还是以桌面型产品为主,比如windows, office,sql server等等。桌面型产品的最大特定就是产品召回或发布热修复的成本太大,而且运行很多关键业务,这就迫使微软必须在产品发布之前投入大量人力物力来充分测试产品用以保障产品的高质量。与微软不同的是,google采用不同的策略来保证软件质量。在理解分析google的质量策略之前,我们必须了解google的采取该策略的根源: Google质量文化:google起源于校园。在有限的资金下,那时候创始人只能使用廉价的机器,把多个廉价的机器放在一起来提高处理能力。这些廉价的机器最大的问题是经常死机或报废,所以google在起始阶段就必须有很强的容错能力。也就是说在系统在部分机器死机或报废的情况下仍然可以提供服务。或者说,系统部分可以出错但是整个系统不可以宕机 (Graceful Degradation)。Google这个从一开始因为被迫置入的高容错能力反而成就了现在他们运行在数据中心上的服务的巨大优势。我们知道通常硬件的出错概率大概在万分之一,如果有一万台机器,其中一台出错概率就达到百分之百。在现在的数据中心里少则几万台,多者几十万台的机器。所以产品的容错能力已经不是可有可无,而是必须有的功能。所以google信奉的原则是单个模块可以出错可以有bug,它通过系统强大的容错能力来保障系统的整体高质量。 互联网产品:google是互联网公司成功的代表。互联网产品的最大特点就是“快”:产品定义快,开发快,反馈快,死掉的也快。所以为了有效利用有限的测试资源,google信奉的另外一个原则是:build the right it before you build it right.也就就是说只有确认了产品的确是用户需要的产品(build the right it)之后才开始提高它的质量(build it right)。道理很简单如果未知产品是否正确的情况下,没有必要浪费资源来提高它的质量。所以google的大部分产品测试人员介入较晚,开发人员不得不自己先测试以保障基本质量。  在理解了goolge对产品质量认识这两个根本出发点后,就不难理解google采用什么样的测试策略了: 1. Dev owns quality Google认为:谁写的的代码谁负责,谁开发的模块谁负责质量。所以开发在写代码的同时也要花很多时间测试,主要是单元测试和模块测试。Google坚信软件质量是先天就创建出来的,而不是通过后天测试测出来的。让开发做测试对产品质量负责不是件容易的事情,google通过主要三个途径:一是减少测试人员数量,所以开发不得不做测试;而是通过一些活动比如test certificate program来正面影响开发做测试;最重要的第三点是通过建立强大的完善的基础设施,使得开发很容易地写测试自动化很容易地运行测试。   2. Tester is to enable developer to test effectively 这个是对传统意义上的测试人员的职责非常大的改变。传统意义上的测试人员的主要职责是寻找产品中的bug。既然google要求开发对质量负责,当然就不太需要传统意义上的测试人员了。所以google中的测试更多时间是在开发测试自动化,开发测试工具,开发基础设施。相对花很少的时间做真正意义上的测试了。所以后来干脆把测试部门从原来的“Test Service”改名子为“engineering productivity”。测试的主要职责是让开发更为容易地做测试。  但是最近两年,随着它的产品的日趋成熟和越来越复杂,google开始加强产品的后期测试。主要原因是虽然开发可以做很多单元和模块测试来保障模块的质量,但是很多bug是在和其它模块集成的时候才被发现。所以google把测试工程师分成两种:一种是和开发一起负责开发的,最要做单元测试,测试工具等。另外一种是面向用户的测试工程师,主要做面向用户的集成场景测试。   3.Continuous Integration…

4

探索性测试揭秘

最近看了不少有关探索性测试的讨论和观点,老实说越看越糊涂。所以忍不住吐槽一下,在这里和大家讨论一下探索性测试。希望对于想学习和尝试探索性测试的朋友有所帮助澄清,或者是更加糊涂,^_^。  探索性测试有很多很多的定义: 百度百科的定义:“同时设计测试和执行测试”。 嗯。。什么意思? Cem 老人家的正式定义:“a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the quality of his/her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project”。啊。。 糊涂了。。。 有人说:“手工测试就是探索性测试”。  更糊涂了。。。…

2

对测试的要求太高?

微软的软件质量控制实践三篇写完了,收到很多评论。不可能一一回答,所以在这里我挑几个评论最多的和有代表性的,和大家再多讨论一下。希望有所帮助。 1. 对测试的要求太高了 在国内培训的时候经常遇到的一个说法:“(比如测试自动化,工具,流程)的确好处很多,但是它对测试的要求太高了”。刚开始的时候我很惊讶,第一次听到对测试要求太高的说法,后来听多了才慢慢意识到这才是问题所在。如果你认为国内的测试比国外落后N年的话,我觉得“对测试的要求太高了“的观念就是导致这个落后的根本原因。我一直在观察和对比国内外测试的区别,当然有技术上的,工具上的,流程上的区别等等,但是这些差别都只是表象,根本的差别是观念上的差别,也就是测试在研发中的真正角色。这个不是找到多少个bug的问题,也不是采用什么测试方法的问题,而是是否把测试做为支撑研发两条腿中的一条腿的问题。测试是一个专门的职业,和开发一样有不同级别。初级人员解决简单的事情,高级人员必须负责解决复杂,高难度的事情。这样才能形成一个完善的测试人员职业发展体系。很多测试经理一直很困惑说我们也在加大在测试上的投资,参加很多技术、流程、管理培训,但是效果都不好。原因就是我们不能总是希望通过学习一个技术,或一个工具来解决观念上的问题,当然没有效果。也容易跟风,刚学会手工测试,又要测试自动化了;刚学会测试自动化;又要ET了。刚学会ET,又要敏捷了。没有观念就没有主见。所以改变观念才是提高软件质量的根本途径。 那么如何改变观念呢?我也不知道。公司老板不愿改变呢?我也没有办法。但是重要的是你知道问题所在了,这就是解决了最大的难题。如果自己都觉得测试没有难度,没有前途或者对测试要求太高了的话,如何指望得了别人?所以我们搞测试的人的一个重要职责就是:把这个观念灌输给其他人,把测试的门槛提高,对测试的要求没用很高只有更高,其它问题也都解决了。    2. Dev不愿意修改bug. 这是一个很多测试抱怨的问题:自己辛辛苦苦找到一个bug,开发却认为不是bug。或者更为令人气愤的是开发在没有沟通之前直接resolved as “by design” or “not repro”。这个情况通常在质量控制成熟度级别(1级或2级)较低的组出现较多。根本上解决的办法是提高整个组的成熟度级别,当然需要在很多方面加以提高,这个问题就随之而去了。可以使用以下几个策略: 首先这里牵涉到两个问题:一个是resolve as “not repro”的问题。很多时候dev resolve as ‘not repro’是因为bug本身不清楚没有足够的信息来判断或进一步investigate(当然他应该和你确认一下先)。所以测试在报bug是一定要记录足够信息。基本原则是当别人在看该bug是否有足够的信息来判断该bug是怎么回事或进一步investigate。我总结过一个好的bug描述应该是Concise,Accurate, Searchable, Entirety, 也就是 CASE 原则。可能你会觉得这需要太多的时间才能报一个bug了。的确是,但是总比你花了两天找到一个bug,花了10秒钟就把bug写完了,结果过两天dev resolve 成not repro强吧。另外就是自动报bug的工具,还有就是创建bug模板等都可以减少报bug的时间。 其次是’by design’的问题。很多时候测试不服气认为就是bug,但是开发不同意修改。我想借用一句话来说明我的观点:a good idea is not really  good  until it is accepted. 也就是说如果你不可以说服别人接受你的主意,再好的主意也没有用。同样的道理你认为的bug,如果不能说服别人,它也不是一个bug。或者bug只有在被修复时才是真正的bug。如果dev/test有分歧的话,通常PM负责一个功能,应该有PM做最后决定;如果没有PM的话,通常有整个team来决定。当然如果你非常肯定,可以继续找更多的理由来支持你的观点。但是最终如果还是不能说服别人的话,还是要服从team的决定,虽然我们常说真理往往掌握在少数人的手里,但是绝大多数时候都是少数人考虑不周。另外一点就是我们通常很少在是不是bug上有分歧,而是在什么时候修复上有分歧。这是另外一个话题了,需要考虑很多其它非技术因素了。   3. 如何做到自动报bug,并把相关的信息放到bug 里面. 我在comments里已经回答过了,就把它拷贝一下吧以是完整:我前面提到微软有很多工具来提高测试人员的工作效率,也就是说把时间花在需要专注的地方而不是在其他繁琐的地方浪费时间。其中一个好的实践就是自动报bug。其实整个过程比较直接:首先用来管理bug的工具应该会有API接口,所以可以使用工具来自动报bug。其次是添加分析处理工具,测试的出错信息比较容易获取,比如测试用例出错了,或者抛异常或者返回错误结果,可以容易地把异常信息或错误信息放到bug里面;分析产品的日志找到错误点有写难度,需要和dev共同努力把测试日志和产品日志通过某些属性(时间戳或操作id)关联起来。或者简单地把相关日志、windows event log,等拷贝到network share,在bug中指向该路径即可。还有对于UI测试,如果测试错误,一定要把当时的屏幕截图抓下来放到bug中去。还是那句话,专注于应该要专注的地方而不是把时间浪费在其它步骤上了,测试用例出错,不应该花太多时间去报bug (最多2分钟)。同样道理有了bug后dev可以直接去investigate,而不是花时间去找日志在那里?那里出错了?等等。有条件的产品组还可以进一步提高,比如工具自动报bug的时候可以到到数据库里根据异常或错误信息查找一遍看一看以前有没有类似的bug,或者做BI,这些信息对于将来的分析和决策非常有帮助,而且也可以帮助预防bug。   —————————————-…

1