《How google tests software》

Google的工程总监讲述Google是如何测试软件的。软件测试和开发人员必看的经典书籍，帮你深入理解软件测试。英文版读书笔记，原汁原味，提炼易懂。

《How google tests software》

• Google's goal :
  • Build the core of a product and release it the moment it is useful to as large a crowd as feasible , and then get their feedback and iterate.
• Principles
  • Stop treating development and testing as separate disciplanes
  • Quality is achieved by putting development and testing into a blender and mixing them until one is indistinguishable from the other
• Test Related Roles
  • Software engineer (SWE)
    • coding of feature
  • SE in Test (SET)
    • concerns more about quality than features
  • Test engineer (TE)
    • put test on behalf of user first and developers second
• Organization
  • Testing is a independent BU. The member is deployed to different project.
  • Testing is owned by the entire engineering team and not just those with the word test in their job title
• Types of Tests
  • small tests
    • verify the behavior of a single unit of code
  • medium tests
    • validate the interaction of one or more unit of code.
  • large tests
    • verify that the system works as a whole all the way from UI down to backend storage system.
  • 70/20/10 percent of small, medium and large tests.
  • small tests lead to code quality. Medium and large tests lead to product quality.
• Code Coverage
  • A great tool for measuring whether a project's tests have a healthy mixture of small, medium and large.
• Code Reviews
  • Reviewing design documents is purposeful and not like reading a newspaper , there are specific goals to pursue
    • completeness
    • correctness
    • consistency
    • design
    • interfaces and protocols
    • testing
• Fast Iteration
  • ACC
    • Attribute
      • They are the quality and characteristics that promote the product and distinguish it from the competition
    • Component
      • They are the core components and chunks of code that make the software what it is
    • Capability
      • Capabilities are the actions the system performs at the command of the user
      • The most important aspect of capabilities is that they are testable.
  • Notes on ACC
    • Capability is described by components and each components' attribute.
    • Each capability should be inked to at least one test case
    • Not all capabilities are equal. Some are more important that others.
• RISKS
  • The enterprise benefits from well calculated risks.
  • risk analysis
    • two factors
      • frequency of failure
        • rarely
        • seldom
        • occasionally
        • often
      • failure impact
        • minimal
        • some
        • considerable
        • maximal
    • Qualitative rather than quantitative analysis
  • If you can't test everything, test the most important stuff first, and the most important stuff is the riskiest stuff.
• BUG
  • Handle on bug rate, simply stop adding features when the incoming bug rate exceeds the team's ability to fix them
  • Bug Handle
    • Report bug -> view bugs -> record & playback bugs
    • Bug create -> assign -> fix (-> re-assign) -> verify (-> re-assign) -> accept
  • Tool： e.g. Bugzilla