<谷歌如何测试> 翻译第三篇

 

经过前两篇的介绍之后，评论里留下许多问题。并没有逐一回复，当然不是想把这些评论置之不理，而是希望在这里和后面的文章中做详细介绍和解释这些问题。从这一篇开始，我将开始讲谷歌是如何测试软件的了。

在谷歌，质量不等于测试，是的，我确定在其他所有的公司也都是这样。“质量不是被测出来的”，这句陈词滥调是再正确不过的了。不管汽车制造还是软件开发，如果在最初的设计建造的时候就有问题，那它永远都会有问题。试问任何一家曾经被迫大量召回汽车的公司，逃避质量问题的代价是多么的昂贵。

但是，“质量不是被测出来的”这句话本身并不像它听起来的那么简单和准确。虽然质量并不是被测出来的，但同样也有证据表明，未经过测试，也不可能开发出有质量的产品。你连测试都没有做过，又是怎么知道产品功能是否正确，并有高质量呢？

对于这种难题，最简单的办法是不要区分开发和测试，不要把他们当成对立的活动。测试和开发【注，两种行为，不是人】最好能手牵手的并行，写一点代码就立刻进行测试，写的越多，测的就要越多。最好是，在编码的同时，甚至在编码之前，就考虑清楚这些代码将如何被测试。测试不是一个单独的工作，测试就是开发的一部分。所以，质量并不等同于测试，当把开发和测试混在一起，搅拌直到分不清他们彼此的时候，就得到了质量。

这就是谷歌的想法，把开发和测试工作混在一起，不分彼此。写点代码，就必须测试，多写一些就多测一些。关键的问题就是谁来做测试工作？ 由于谷歌的专职测试人员非常的少，唯一的答案就只能是开发人员。还有比实际写代码的开发人员更适合来测试这些代码的人吗？还有比程序的作者更懂得怎样去发现程序bug的吗？是谁更想知道程序在第一次运行时是否有没有问题呢？谷歌之所以用这么少的专职测试人员的原因就是开发对质量负全责。实际上，如果一个团队在过于依赖测试的时候，通常情况下这个团队在开发上一定也会有问题。如果在这个团队里，测试人员比较多，这也是一个强烈的信号，这表明开发和测试融入到一起的程度还不够，失衡了，缺乏测试，单纯地增加测试人员并不能解决任何问题。

这意味着，对于质量来说，预防问题比发现问题本身更重要。质量是开发人员的问题，而不是测试人员的问题。通过把测试工作融入到开发过程中，我们能降低那些富产Bug的人的出错机会，不仅可以避免了大量最终用户的使用问题，而且还可以极大地降低测试人员报无效Bug的数量。在谷歌软件测试工程师的工作目标就是检查这种预防措施是否有效，软件测试工程师不停地寻找一些证据来证明作为bug的作者和预防者的“软件开发工程师-软件测试开发工程师”组合是否存在问题，一旦发现任何不正常，就会拉响警笛。

这种开发和测试一体的场景随处可见，不管是在代码审核的时候问“你的测试呢？”，还是在厕所蹲坑里张贴着的最佳测试实践–臭名昭著的马桶测试指南【译者注，参见google test blog，有关于”Testing On The Toilet“的更多介绍】。测试是开发过程中必不可少的一环，质量是开发和测试合体的产物。软件开发工程师，软件测试开发工程师，软件测试工程师，所有的人都是测试人员。

如果你所在的公司也想要做这种开发和测试的统一，请也给大家分享一下其中经验和教训。如果没有，这将是一个帮助你公司的机会：让开发和质量划等号。你大概知道谚语里说的，鸡和猪为了一顿有培根和鸡蛋的早餐都乐于奉献自己，但是猪却牺牲了。好吧，这就是事实，尝试跑到开发工程师那里，对他们”哼哼“（猪叫声）两声，看他们是否也用”哼哼“来回应，如果他们”咯咯哒“（鸡叫声）来回应，那就说明有问题了。【译者注，崩溃了，这里比较难懂。James这里引用了一个猪和鸡的英语谚语，（参见，http://en.wikipedia.org/wiki/The_Chicken_and_the_Pig ），谚语的意思大概是，猪和鸡都参与制作培根鸡蛋早餐，猪变成了猪肉（培根），鸡只下了一个蛋，说明对于早餐，猪和鸡的奉献程度是不同的。并在这里把测试工程师比喻成鸡，开发工程师比喻成猪，早餐就是质量，猪的奉献大。测试人员跑到开发人员那里，如果发现他们没有做猪的事情，早餐将做不成，那说明质量也将会有问题。】

 

公直
2012/3/16

 
英文原文，

How Google Tests Software – Part Three
Wednesday, February 16, 2011 2:47 AM
http://googletesting.blogspot.com/2011/02/how-google-tests-software-part-three.html
By James Whittaker

Lots of questions in the comments to the last two posts. I am not ignoring them. Hopefully many of them will be answered here and in following posts. I am just getting started on this topic.

At Google, quality is not equal to test. Yes I am sure that is true elsewhere too. “Quality cannot be tested in” is so cliché it has to be true. From automobiles to software if it isn’t built right in the first place then it is never going to be right. Ask any car company that has ever had to do a mass recall how expensive it is to bolt on quality after-the-fact.

However, this is neither as simple nor as accurate as it sounds. While it is true that quality cannot be tested in, it is equally evident that without testing it is impossible to develop anything of quality. How does one decide if what you built is high quality without testing it?

The simple solution to this conundrum is to stop treating development and test as separate disciplines. Testing and development go hand in hand. Code a little and test what you built. Then code some more and test some more. Better yet, plan the tests while you code or even before. Test isn’t a separate practice, it’s part and parcel of the development process itself. Quality is not equal to test; it is achieved by putting development and testing into a blender and mixing them until one is indistinguishable from the other.

At Google this is exactly our goal: to merge development and testing so that you cannot do one without the other. Build a little and then test it. Build some more and test some more. The key here is who is doing the testing. Since the number of actual dedicated testers at Google is so disproportionately low, the only possible answer has to be the developer. Who better to do all that testing than the people doing the actual coding? Who better to find the bug than the person who wrote it? Who is more incentivized to avoid writing the bug in the first place? The reason Google can get by with so few dedicated testers is because developers own quality. In fact, teams that insist on having a large testing presence are generally assumed to be doing something wrong. Having too large a test team is a very strong sign that the code/test mix is out of balance. Adding more testers is not going to solve anything.

This means that quality is more an act of prevention than it is detection. Quality is a development issue, not a testing issue. To the extent that we are able to embed testing practice inside development, we have created a process that is hyper incremental where mistakes can be rolled back if any one increment turns out to be too buggy. We’ve not only prevented a lot of customer issues, we have greatly reduced the number of testers necessary to ensure the absence of recall-class bugs. At Google, testing is aimed at determining how well this prevention method is working. TEs are constantly on the lookout for evidence that the SWE-SET combination of bug writers/preventers are screwed toward the latter and TEs raise alarms when that process seems out of whack.

Manifestations of this blending of development and testing are all over the place from code review notes asking ‘where are your tests?’ to posters in the bathrooms reminding developers about best testing practices, our infamous Testing On The Toilet guides. Testing must be an unavoidable aspect of development and the marriage of development and testing is where quality is achieved. SWEs are testers, SETs are testers and TEs are testers.

If your organization is also doing this blending, please share your successes and challenges with the rest of us. If not, then here is a change you can help your organization make: get developers fully vested in the quality equation. You know the old saying that chickens are happy to contribute to a bacon and egg breakfast but the pig is fully committed? Well, it’s true…go oink at one of your developer and see if they oink back. If they start clucking, you have a problem.

 

 

From：http://sdet.org/?p=160