摘要：
《How Google Tests Software》这本书在4月初已经在Amazon.com上开卖了。据一位看了这本书的一位曾经在Google工作的朋友说，这本书所写的内容和James在博客http://googletesting.blogspot.com上的连载文章内容基本是一致的，只不过书上的内容更系统化，内容更充实一些。这几天抽了3天时间把他们都翻译出来了，以飨那些在测试工作中迷茫的读者们。这个博客连载国内我之前也看到过翻译，但我看到的版本貌似是机器翻译的，或者说机器翻译+人工校对的，比较晦涩，我这里翻译的文章都是通读后的意译，加入了一些结合我自己工作经验的理解，对于拿不准的地方也贴上 阅读全文
摘要：
（一）google在公司的大层面组织上有很多的Focus Area，search, apps, ads, mobile, operating system这些都是不同的FA。测试隶属于其中的一个FA，这个FA的名字叫Engineering Productivity。这个FA由很多纵向的横向的学科构成... 阅读全文
摘要：
相比SWE和SET，TE在Google是一类新职位。因此，这个职位的角色定义还在进行中。当前Google的这代TE正在为这个职位开辟一条道路，这样就能更好的指导后面招聘进来的TE来开展工作。我们这里描述的是在Google新兴起来的一个最好过程（It is the process that is emerging as the best within Google that we present here）。并不是每个项目都需要TE。那些在产品初期的实验性尝试，没有良好定义的任务或用户场景的项目势必不会引起很TE的注意。如果一个产品看起来没什么希望（作为一个概念他不能通过审核）或者尚未能吸引用户 阅读全文
摘要：
SET是专注于测试的软件工程师。他们是乐于编写测试功能的软件工程师。首先说，SET是开发者，在招聘的时候我们就会说这个工作是100%的编码工作，晋升阶梯中的描述也是如此。当我们面试SET的时候，对于写代码能力的要求跟SWE几近相同，之外我们还会强调SET要懂得如何测试他们自己的代码。换句话说，SWE和SET都要回答编码问题，但是SET要面对更多的测试问题。你应该猜到了，这个角色很难做，而且造成Google的SET数量很少的原因，可能完全不是因为我们有针对生产率的一套魔法公式，而在于：把我们的工程实践应用到SET技能的人真的很难找。我们优化这项重要的工作并且围绕这些人建立流程。SET不会参加到前 阅读全文
摘要：
在测试层级的划分方面我们没有采用代码级、集成级、系统级这样的分类方式，取而代之的小测试、中测试、大测试，这样做是为了强调测试的规模而不是外在形式。小测试只会覆盖一小撮代码，然后是中、大测试。不论是SWE、SET、还是TE，都会执行这三类的测试，可能是通过自动化的方式开展也可能是手工的方式。小测试通常（但不总是）通过自动化的方式来运行，它只会运行一个函数或一个模块的代码。通常他们都是由SWE或SET来完成编写的，他们的运行可能会需要mock环境，TE通常会在需要诊断一个具体问题的时候直接拿过来运行。对于小测试来说他们关注的是些典型的问题，如数据损坏、错误条件或一个错误。一个小测试要回答的问题是： 阅读全文
摘要：
匍匐、步行、跑步向前之所以Google的测试人员相比其他公司非常少但是却还可以保持较好的质量，一个首要的原因就是：我们很少试图一次性发布很多功能。事实上，我们做的恰恰相反：首先构建一个产品的核心部分，并在他能惠及尽量一个大群体客户的时候就发布他，然后收集反馈意见并且迭代改进。我们就是这么来开发Gmail的，以至于beta标签在这个产品上呆了4年。这个标签也让我们的用户知道这是一个在不断完善的产品。直到我们能够保证用户email数据达到99.99%的可用性的时候我们才把这个beta标签取消。看到了没，质量的改善贯穿整个工作当中。通过这个过程（确保质量）并不是一个很冒险的过程。事实上，为了能到达b 阅读全文
摘要：
SWEorSoftware Engineer。写功能代码，并发布到终端用户。他们写设计文档、设计数据结构，并且花大量的时间write和review代码。他们要写大量的测试，包括测试驱动设计、单元测试、参与小、中、大的测试。他们对任何他们碰过的代码质量负责，包括写的、修复的、修改的。SETorSoftware Engineer in Test。也是一个开发者，但是他的侧重点在于可测性。他们review设计，并且审阅代码的质量、风险。他们重构代码并且使他们具备更好的可测性。他们编写单元测试框架、自动化测试框架。从写代码这个角度来看，他们是SWE的伙伴，但是他们关心的是如何从代码层面上提高质量、测试 阅读全文
摘要：
首先明确，质量是测试不出来的。有个比喻很有意思：不能通过反复测试来提高质量，这就好像你不能通过反复称重来减肥一样。在Google，质量不等于测试，有些公司则不然。“质量不能通过测试而植入”这个是老生常谈了，我们不必去怀疑他的正确性。从手机到软件，如果你没有在一开始就把它构建好，那么他永远不会正确的工作。如果你不知道一开始不重视质量的代价，那么去问问陷入“召回门”的汽车厂吧。“质量不能通过测试而植入”这话本身并不通俗，它也不是一个准确的描述。可是为什么这么说？因为显然，如果没有测试你不可能开发出什么高质量的东西。对啊，如果你不测试，你怎么知道你开发出来的东西就是高质量的呢？解决这个问题的简单方法 阅读全文
摘要：
google在公司的大层面组织上有很多的Focus Area，search, apps, ads, mobile, operating system这些都是不同的FA。测试隶属于其中的一个FA，这个FA的名字叫Engineering Productivity。这个FA由很多纵向的横向的学科构成，测试是其中最大的一个学科。Eng Prod这个FA由下面的部分组成：product team。公司内部使用的工具还有开源工具都由它来生产，这些都是提高生产率的工具，包括代码分析工具、IDE、case管理工具、自动化测试工具、编译工具、编译系统、代码版本控制工具、code review工具、bug dat 阅读全文