Jessie对《How Google Tests Software》的笔记(8)

How Google Tests Software
  • 书名: How Google Tests Software
  • 作者: James A. Whittaker/Jason Arbon/Jeff Carollo
  • 页数: 320
  • 出版社: Addison-Wesley Professional
  • 出版年: 2012-4-2
  • 第4页
    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 you build is high quality without testing it?
    The simple solution to this conundrum is to stop treating development and test as separate disciplines.
    Code a little and test what you build. Then code some more and test some more.
    Quality is achieved by putting development and testing into a blender and mixing them until one is indistinguishable from the other.
    The key here is who is doing the teting. Developer
    2013-03-30 10:27:14 7回应
  • 第15页
    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.
    Google SWEs are feature developers. Google SETs are test developers. Google TEs are user developers. In this book, we are concerned primarily with the activity of the SET and TE roles and include the activity of the SWE as a subset of both of these roles because the SWE is heavily involved but usually under the direction of an engineer who actually has the word test in his or her title.
    2013-04-02 21:32:27 回应
  • 第22页
    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 decisions optimized for this local and narrow view of a product. A good SET must take the exact opposite approach and assume not only a broad view of the entire product and consider all of its features but also understand that over a product's lifetime, many SWEs will come and go and the product will outlive the people who created it.
    2013-04-05 10:03:33 回应
  • 第25页
    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 additional pair of eyes on a body of work. As SWEs fill in the various sections of their design docs, they should be diligent about getting peer feedback prior to sending their document to a wider audience for official review.A good SET is eager to review such documents and proactively volunteers his time to review documents written by the team and adds quality or reliability sections as necessary.
    2013-04-07 15:04:07 回应
  • 第29页
    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 that we can control the interactions at those interfaces and ensure good test coverage.
    The next step is to build a lightweight automation framework that allows the mocked system to be built and executed. That way, any SWE who writes code that uses one of the mocked interfaces can do a private build and run the test automation before they check their code changes into the main codebase, ensuring only well tested code gets into the codebase in the first place.
    This is one key area where automation excels: keeping bad code out of the ecosystem and ensuring the main codebase stays clean.
    2013-04-07 15:11:00 回应
  • 第75页
    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 is to decide things such as:
    - Where are the weak points in the software?
    - What are the security, privacy, performance, reliability,usability, compatibility, globalization, or other concerns?
    - Do all the primary user scenarios work as expected? Do they work for all international audiences?
    - Does the product interoperate with other products (hardware and software)
    - In the event of a problem, how good are the diagnostics?
    2013-04-09 11:05:04 回应
  • 第188页
    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:52:37 回应
  • 第230页
    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.
    2013-04-23 10:07:11 1回应