google软件测试之道读后感(二)

这几天又翻了几页这本书,觉得妙语连珠,关键语录摘抄如下,并补充自己的一些思考:

“如果你想要求一个团队去尝试新的事物或者做某些改进,给他们提供一个联系人会更好一些,这个联系人来源于更大的社区,并可以从他那里得到帮助”;

“不要陷入尝试去创建一个包含独立指标的完美系统的陷阱中。对所有人都完美的事情是不存在的。在没有可替代的方案时,在合理的地方达成一致并勇往直前是很重要的。需要灵活的时候就灵活一些,但一定要坚持你的原则底线”。

当考虑团队建设方面时,在以前总是收获理想很丰满,现实很骨感的局面,最后总是不了了之的结局。这比没开展还坏,因为会打击团队的积极性,忙乱一顿,却看不到明显的产出,而且有很强的受挫感。这里提到要有一个指导者,而且最好有一个这样的联盟,大家一起来做这件事情,形成一种社区的氛围,那事情的成功性会较大。而且,做事情,不要太过死板,既然是尝试,就没有板上钉钉的事情,一直强调考核和目标,这样的行政指标会让人反感和排斥。适当的转弯,可以让团队走的更远。

“专注于你的用户,理解他们的需求并解决他们的问题。”

“缺陷驱动开发,一旦用户发现了一个bug,我就立刻去修复它,然后再宣布它没有问题了,更加完美无瑕”。

产品的最终目标,是满足用户的需求,无论是真实功能上的需求,还是用户无法提出来的隐形需求。要做到缺陷驱动开发,当然不能把缺陷都放到市场上等待用户发现,而是在实验室内多次迭代,多次从用户角度去试用,通过快速的迭代,持续的集成来实现。这是敏捷的思想,我想到了今天,世界上测试技术那样多,但有一点是不变的,那就是要快。只有测试足够的快,能快速执行,快速出结果,快速评估,才能提高生产力和效率。

“试验性工作、尚无明确目标或用户故事的早期产品,TE很少参与,甚至不参与。”

“过度早期地投入测试意味着资源上的浪费,尤其是在SET已经深度介入的时候”

“以策略上将,给一个项目配备多少测试人员,取决于项目风险和投资回报率”

”TE擅长发现需求中的模糊之处,分析沟通不明确的问题“

”一旦找到薄弱点,TE就会通过测试使软件出错,然后与开发、产品、SET一起推动解决这些bug“

”如果做测试计划已经来不及了,那就干脆不做了。如果一个项目最需要的是测试,那就做一个简单够用的指导性计划,一些测试教条所倡导的从头就介入的模式,在google并不适用。“

google一直在强调,传统的测试模式在快速迭代的今天已经有些跟不上了,至少从我工作的经验来看,确实是这样。测试跟不上研发的进度,研发抱怨测试拖了项目的后腿。测试什么时候介入,也无需一味按照传统的开发模型来生搬硬套。但是这里提到的测试指的是系统测试,而其他的测试,例如单元测试、集成测试,以及测试脚本的开发和维护,则是在项目之初就开始了。测试的角色是更加全方位的,测试是真正意义上的测试开发工程师,产生的测试代码和产品功能代码一样属于产品功能完整性的一部分。这其实给测试提出了更大的要求和期待,既要熟悉测试方法,兼具用户视角,又要有很强的编程能力,是真正意义上的开发工程师。google内部对测试工程师的角色划分也非常细致,可以看出是真正重视人员培养的。越发觉得,别人是真正讲求效率和实效性的,和自己当下的处境相比,现实差距太大啦。。。

”测试人员不应该对测试文档过于珍爱。糟糕的测试用例不会受到足够的关注和改善,他们只会被抛弃,而最后留下来的是更好的测试用例。“

”作为一种测试文档,测试计划的生命周期是所有测试产物中最短的“

”测试计划是最早出现,最先被遗忘的测试产物“

”伴随着计划内或计划外的变更,维护一份测试计划是要花费大量精力的,除非多数项目的成员会定期查看,否则测试计划并没有什么价值“

这里道出了现实中测试计划的尴尬局面。有时候甚至会产生要测试计划何用的叹息,测试计划执行完后,我们对于测试的程度和产品质量的好坏仍然不能评估,不知道还有哪些没测,哪些是风险点,哪些对于产品来说是至关重要的。每次的测试计划不能相互关联,一次测试计划完成后,就永久性的搁置。而且最大的尴尬是,测试计划似乎无人在乎,开发不在乎,连测试人员也不太在乎,测试中随时可能会更改测试用例(有些步骤被证明是失效的,维护测试用例需要花费很大的精力),测试主管又不能根据测试计划做出合理评估!google提出的ACC方法确实有见地,在测试中一直在追问产品的核心价值,一切活动溯源都是产品的定位与价值。这其实给我们现在的测试管理敲了个警钟,要不忘初心!作为测试管理人员,是否能在10分钟内准确说出产品的特质?如果不能,说明对产品不够熟悉,还不能有效地测试它。一切都是为了提高效率,那就要时刻牢记最终的目标,这是测试的愿景,否则,在浩瀚的测试海洋中,是会迷失方向的。

愿在工作中,能尽快实践书中的一些理念,对于测试,实在要有长远的信心和行动才行!

时间: 2024-10-05 00:08:16

google软件测试之道读后感(二)的相关文章

Google软件测试之道(二):测试工程师

一种面向用户的测试角色 一种用户开发者,TE首先必须是工程师,Google的TE他综合了开发者仰慕的技术能力和以用户为中心检查软件质量而对开发者产生一定制约的能力.在研发的早期阶段,功能还在不断变化,最终功能列表和范畴还没有确定,通常TE没有太多工作可做.在TE进入产品时,需要考虑以下问题: 当前软件薄弱点在哪里? 有没有安全.隐私.性能.可靠性.可用性.兼容性.全球化和其他方面的问题? 主用户场景是否功能正常?对于全世界不同国家的用户都是这样吗? 这个产品能与其他产品互操作吗? 当发生问题时,

转《Google软件测试之道》

<Google软件测试之道>,一直听朋友讲起这本书,出于琐事太多,一直没机会拜读,最近部门架构觉得我们IT部门的技术太low,就给我们挑选了一些书籍,让我们多看看... 个人的一种学习习惯吧,就做了笔记,将自己的学习理解感触写下来... 预计会分为五部分写这些学习笔记,分别是Google软件测试基础介绍.软件测试开发工程师.软件测试工程师.测试经理以及附录其他部分... 快乐阅读,快乐测试,祝愿你总能发现(并修复)BUG... ----James Whittaker.Jason Arbon.J

《Google软件测试之道》

Google软件测试之道 Google对质量的理解 质量不等于测试,即质量不是被测出来的 开发和测试应该并肩齐驱,测试就是开发过程中不可缺少的一部分 质量是一种预防行为而不是检测 Google对软件测试的划分 抛却复杂的专业术语,简单按照测试范围去划分: 小型测试:对一个代码单元的测试,通常就是单元测试 中型测试:对两个或多个模块之间交互的测试,通常类比于“集成测试” 大型测试:对一个应用系统及其子系统整体的测试,通常类比于“端到端测试” 这样划分的好处有: 容易定位问题:测试范围从小到大,各自

《Google软件测试之道》测试开发工程师

拖延了将近半年的草稿,断断续续的写完了.之前草草翻看完这本书,关注点主要在TE上,而关于SET的部分则只是浏览,最近后知后觉,又翻出了这本书,重新看了一遍,又有新收获. 就说说Google的SET是如何做的,以及个人的一些思考和收获吧,寥有慰藉... Google的测试流程可以简练的概括为:让每个工程师都注重质量.而在工作流程引入过程中也伴随着一些致命的缺陷,下面简述下Google是如何解决以及其测试流程的是如何进化的. ①.测试并不能保证产品质量.需要一直谨记的一点:质量是内建的,而不是外加的

《Google软件测试之道》- Google软件测试介绍

<Google软件测试之道>- Google软件测试介绍 2015-05-21 目录 1 质量与测试  2 角色  3 组织结构  4 爬.走.跑  5 测试类型  相关链接 与Microsoft相比,Google的测试团队并非雄兵百万,更象是小而精的特种部队,依靠的是出色的战术和高级武器.Google信奉“少则清晰”. 1 质量与测试 返回 测试是开发过程中必不可少的一部分,当开发过程和测试一起携手联姻时,即是质量达成之时. 2 角色 返回 软件开发工程师(software engineer

Google软件测试之道 pdf下载

引领一代风骚的明星企业google, 推出过很多成功优秀的产品,搜索引擎不用说,譬如Gmail ,Chrome, Google Doc, G+等等等等,也推出过很多短命的产品,譬如Google Wave等等. 作为一个时常需要推出新产品,但又要根据用户反馈而做进一步选择继续还是放弃的企业,作为一个需要让产品稳定健壮以保持客户满意度的明星企业,该如何测试是一个很大的问题.Google的经验非常值得借鉴. 该书的作者是Google测试的Senior Director(如果我没记错的话),在测试领域有

《Google软件测试之道》心得笔记

Google软件测试介绍 把开发和测试融合在一起--开发和测试必须同时展开 开发人员自己要对自己写的代码负责,比专职的测试人员更适合做测试工作. 测试开发工程师SET 对于Google拥有很少量的测试人员的情况下,还可以取得不错的成果,核心原因在于Google从来不会再一次产品发布中包含大量的功能,实际上,做法恰恰相反,在一个产品的基本核心功能实现之后,就立即对外发布使用,然后从用户那里得到真实的反馈. 软件测试开发工程师(SET) Google的四大主要开发语言:C++.Java.Python

Google软件测试之道(一):软件测试开发工程师

设计文档 项目发起人要做的第一件事情就是设计文档.这是一个动态的文档.最早期的项目设计文档,主要包括项目的目标.背景.团队成员.系统设计.团队成员一起协同完成设计文档的不同部分.对于一些大规模的项目,需要针对主要子系统也创建相应的设计文档.在初期版本完成后,将来需要完成的工作清单也可作为项目路标.从这一点讲,设计文档必须经过相关技术负责人审核.作为SET,比较幸运的是在初期阶段加入了项目.SET在团队中有一个巨大优势,就是拥有产品方面最广阔的视野.通常代码复用和模块交互方面的设计会由SET来做,

读《微软的软件测试之道》有感(上)

在这个电子书漫天飞的年代,我居然仍然喜欢读纸书,喜欢一边读一遍闻书的味道,就像品尝一顿美味的大餐一样.最近得了一本<微软的软件测试之道>,啃了一段时间了,每次重新拿起来看就觉得里面的内容忘得一干二净了,想起之前有位领导总是教导我们:“要不断总结,要累积,这样才会进步!”之前每次听这话都觉得烦,后来工作久了才知道总结有多重要,如今为了记住这本书的内容,我决定写个读后感,想到哪里写到哪里. 第一部分: 第一章<微软的软件工程> 第二章<微软的软件测试工程师> 第三章<