How Google Tests Software的笔记(9)

>我来写笔记

按有用程度 按页码先后 最新笔记

  • Jessie

    Jessie

    The second fatal flaw is also related to developers and testers separated by organizational boundaries. Testers identify with their role and not their product. Whenever the focus is not on the product, the product suffers. After all, the ultimate purpose of software development is to build a product, not to code a product, not to test a product, not to document a product.   (1回应)

    2013-04-23 09:55

  • Jessie

    Jessie

    The first advice toward this end is know your product. Given any question about how to use the product, the TEM should be an expert. A related second piece of advice is to know your people. As a manager, a Google TEM is a product expert and understands the work that needs to get done but plays only a small role in actually performing that work.

    2013-04-22 20:35

  • Jessie

    Jessie

    The Test Engineer (TE) plays a related but different role where the focus is on user impact and risk to the overall mission of the software product. After they are engaged, TEs do not have to start from scratch. There is a great deal of test engineering and quality-oriented work performed by SWEs and SETs, which becomes the starting point for additional TE work. The initial engagement of the TE...

    2013-04-09 10:27

  • Jessie

    Jessie

    The larger an automation effort is, the harder it is to maintain and the more brittle it becomes as the system evolves. It's the smaller, more special purpose automation that creates useful infrastructure and that attracts the most SWEs to write tests. At Google, SETs take the following approach. We first isolate the interfaces that we think are prone to errors and create mocks and fakes so th...

    2013-04-07 15:04

  • Jessie

    Jessie

    Indeed, SETs have the one major advantage of being the engineer on the team with the broadest view of the product. A good SET can put this breadth of expertise to work for the more laser-focused developers and have impact far beyond the code they write. Generally broad patterns of code reuse and component interaction design are identified by SETs and not SWEs. There is no substitute for an add...

    2013-04-07 14:49

  • Jessie

    Jessie

    Test is just another feature of the application, and SETs are the owner of the testing feature. SETs also participate in reviewing code written by SWEs and vice versa. quality is not important until the software is important. SWEs often get caught up in the code they are writing and generally that code is a single feature or perhaps even smaller in scope than that. SWEs tend to make dec...

    2013-04-05 09:04

  • Jessie

    Jessie

    There is a different kind of thinking involved in writing feature code and writing test case. It becomes necessary to distinguish between a feature developer and a test developer. For feature code, the mindset is creating and considering users, use cases, and workflow. For test code, the mindset is about breaking and writing code that will draw out cases that disrupt the user and his workflow. ...

    2013-04-02 21:09

  • Jessie

    Jessie

    The first piece of advice I give people when they ask for the keys to our success: Don't hire too many testers. How does Google get by with such small ranks of test folks?If i had to put it simply, I would say that at Google, the burden of quality is on the shoulders of those writing the code. Quality is never "some tester's" problem. Quality != Test How does one decide if what yo...   (7回应)

    2013-03-30 10:26

  • exiang

    exiang

    Quality is not equal to test. Quality is achieved by putting development and test- ing into a blender and mixing them until one is indistinguishable from the other.

    2012-07-03 16:09

笔记是你写在书页留白边上的内容;是你阅读中的批注、摘抄及随感。

笔记必须是自己所写,不欢迎转载。摘抄原文的部分应该进行特殊标明。

How Google Tests Software

>How Google Tests Software