AUD Library Catalog

Image from Google Jackets
Normal view MARC view

Testing Extreme Programming / Lisa Crispin, Tip House.

By: Contributor(s): Series: XP seriesPublication details: Boston : Addison-Wesley, c2003.Description: xxi, 306 p. : ill. ; 24 cmISBN:
  • 0321113551 (pbk.) :
Subject(s): LOC classification:
  • QA76.76.D47 C75 2003
Contents:
The XP Tester Role -- How XP Solves Testing and Quality Assurance Problems -- Wolves in Sheep's Clothing -- Why XP Teams Need Testers -- The Tester's Contribution, Illustrated -- Shun the Dark Side -- How XP Teams Benefit from Having Testers -- Checks and Balances -- Acceptance Tests versus Unit Tests -- Navigating for XP Projects -- XP Testing Values -- Communication -- Simplicity -- Feedback -- Courage -- Overview of the XP Tester Role -- XP Tester's Bill of Rights -- XP Tester Activities -- Quality and XP -- Setting Quality Criteria -- Who Is Responsible for Quality? -- Test Drive through an XP Project -- User Stories and Release Planning -- The Tester's Role in Up-Front Activities -- Goals of Up-Front Tester Activities -- Identifying Hidden Assumptions -- A Process for Finding Hidden Assumptions -- Defining High-Level Acceptance Tests -- Basic Acceptance Test Definitions -- High-Level Acceptance Test Estimates -- Ways to Estimate Acceptance-Test Effort -- Enabling Accurate Estimates during Release Planning -- Why We Care about Estimates -- How You Can Improve Estimate Accuracy -- Planning the First Iteration -- Overview of Iteration Planning -- The Tester's Role in Iteration Planning -- Defining and Estimating Testing and Test Infrastructure Tasks -- Identifying and Estimating Test Infrastructure Tasks -- Identifying and Estimating Functional and Acceptance Testing Tasks -- A Note on Separate Test Teams -- Acceptance Tests and Quality -- Acceptance Test Details -- Internal and External Quality -- Nailing Down the Details -- Picking the Customer's Brain (and the Programmers'!) -- The Good, the Bad, and the Ugly -- Optional Tests -- Getting Creative -- Lights-Out Test Design -- Writing Acceptance Tests -- Executable Tests -- If You Have Trouble Getting Started -- Organizing Acceptance Tests -- Version Control of Acceptance Tests -- Executable Test Files -- Organizing Acceptance Tests in Spreadsheets -- Test Design and Refactoring -- Establishing the Initial System State -- Tests That Leave the System State Unchanged -- Coupling between Tests -- Manual Tests -- What!?!! -- Manual Tests Are Unreliable -- Manual Tests Undermine the XP Testing Practice -- Manual Tests Are Divisive -- The Wings-Fall-Off Button -- What If You Have Manual Tests? -- Test Automation -- Modular Tests -- Data-Independent Tests -- Self-Verifying Tests -- Making Executable Tests Run -- Linking the Executable Test to an Application Test Class -- Defining the Application Test Class -- Calling the Code to be Tested -- Running the Test -- Getting Additional Tests to Run -- Combining Multiple Tests into Test Suites -- Running Executable Tests through Other Interfaces -- Code Missed by Direct Calls -- Expanding Coverage of the Executable Tests -- Interfacing to a Test Tool -- Creating an Application Test-Interface Class -- Refactoring the Direct-Call Interface -- Refactoring the Application Test Class -- Creating a Tool-Specific Interface Class -- One Team's Experience with Direct-Call Test Automation -- Driving the System with a Test Tool -- WebART Overview -- Main WebART Script -- Login Module -- Validation Criteria -- Bugs on the Windshield: Running Acceptance Tests -- How Often Do You Run Acceptance Tests? -- Educating the Customer -- Acceptance Criteria -- Defect Management -- Road Food for Thought -- Looking Back for the Future -- Keep On Truckin': Completing the XP Road Trip -- Regression Testing -- Catching Up -- Maintenance? -- The Release -- When XP Projects End -- Road Hazard Survival Kit -- Challenges in "Testability" -- Designing for Testability -- Selecting and Implementing Tools -- Evolving Tools -- Test Tools -- Other Tools Related to Quality -- Choosing an Off-the-Shelf Tool -- Implementing Tools -- Experimenting with Tools -- Project Tune-Ups -- Office Space -- Accessorizing for XP -- Metrics -- Test Environment -- Other Obvious Best Practices -- Additional Tester Duties -- Introducing XP to Your Organization: A Tester's Point of View -- Test Phases and Practices -- Introducing People to the XP Tester Role -- Helping XP Testers Succeed -- XP Testing with Blended Practices -- What If You Don't Have Enough Testers? -- XP for Projects of Unusual Size -- Adjusting XP -- Advance Planning Pays Off -- Working with Customers -- Satisfying Customer Test Documentation Requirements -- Iteration Planning and Execution for Large or Multilocation Projects -- Extreme Testing without Extreme Programming -- Gathering Requirements -- System Design -- Planning and Defining Tests -- Running Tests -- Retrospectives -- Let Worry Be Your Guide.
Summary: Testing is a cornerstone of XP, as tests are written for every piece of code before it is programmed. This workbook helps testers learn XP, and XP devotees learn testing. This new book defines how an XP tester can optimally contribute to a project, including what testers should do, when they should do it, and how they should do it.
Holdings
Item type Current library Home library Shelving location Call number Status Date due Barcode
Books Books American University in Dubai American University in Dubai Main Collection QA 76.76 .D47 C75 2003 (Browse shelf(Opens below)) Available 648451

Includes bibliographical references (p. 287-289) and index.

The XP Tester Role -- How XP Solves Testing and Quality Assurance Problems -- Wolves in Sheep's Clothing -- Why XP Teams Need Testers -- The Tester's Contribution, Illustrated -- Shun the Dark Side -- How XP Teams Benefit from Having Testers -- Checks and Balances -- Acceptance Tests versus Unit Tests -- Navigating for XP Projects -- XP Testing Values -- Communication -- Simplicity -- Feedback -- Courage -- Overview of the XP Tester Role -- XP Tester's Bill of Rights -- XP Tester Activities -- Quality and XP -- Setting Quality Criteria -- Who Is Responsible for Quality? -- Test Drive through an XP Project -- User Stories and Release Planning -- The Tester's Role in Up-Front Activities -- Goals of Up-Front Tester Activities -- Identifying Hidden Assumptions -- A Process for Finding Hidden Assumptions -- Defining High-Level Acceptance Tests -- Basic Acceptance Test Definitions -- High-Level Acceptance Test Estimates -- Ways to Estimate Acceptance-Test Effort -- Enabling Accurate Estimates during Release Planning -- Why We Care about Estimates -- How You Can Improve Estimate Accuracy -- Planning the First Iteration -- Overview of Iteration Planning -- The Tester's Role in Iteration Planning -- Defining and Estimating Testing and Test Infrastructure Tasks -- Identifying and Estimating Test Infrastructure Tasks -- Identifying and Estimating Functional and Acceptance Testing Tasks -- A Note on Separate Test Teams -- Acceptance Tests and Quality -- Acceptance Test Details -- Internal and External Quality -- Nailing Down the Details -- Picking the Customer's Brain (and the Programmers'!) -- The Good, the Bad, and the Ugly -- Optional Tests -- Getting Creative -- Lights-Out Test Design -- Writing Acceptance Tests -- Executable Tests -- If You Have Trouble Getting Started -- Organizing Acceptance Tests -- Version Control of Acceptance Tests -- Executable Test Files -- Organizing Acceptance Tests in Spreadsheets -- Test Design and Refactoring -- Establishing the Initial System State -- Tests That Leave the System State Unchanged -- Coupling between Tests -- Manual Tests -- What!?!! -- Manual Tests Are Unreliable -- Manual Tests Undermine the XP Testing Practice -- Manual Tests Are Divisive -- The Wings-Fall-Off Button -- What If You Have Manual Tests? -- Test Automation -- Modular Tests -- Data-Independent Tests -- Self-Verifying Tests -- Making Executable Tests Run -- Linking the Executable Test to an Application Test Class -- Defining the Application Test Class -- Calling the Code to be Tested -- Running the Test -- Getting Additional Tests to Run -- Combining Multiple Tests into Test Suites -- Running Executable Tests through Other Interfaces -- Code Missed by Direct Calls -- Expanding Coverage of the Executable Tests -- Interfacing to a Test Tool -- Creating an Application Test-Interface Class -- Refactoring the Direct-Call Interface -- Refactoring the Application Test Class -- Creating a Tool-Specific Interface Class -- One Team's Experience with Direct-Call Test Automation -- Driving the System with a Test Tool -- WebART Overview -- Main WebART Script -- Login Module -- Validation Criteria -- Bugs on the Windshield: Running Acceptance Tests -- How Often Do You Run Acceptance Tests? -- Educating the Customer -- Acceptance Criteria -- Defect Management -- Road Food for Thought -- Looking Back for the Future -- Keep On Truckin': Completing the XP Road Trip -- Regression Testing -- Catching Up -- Maintenance? -- The Release -- When XP Projects End -- Road Hazard Survival Kit -- Challenges in "Testability" -- Designing for Testability -- Selecting and Implementing Tools -- Evolving Tools -- Test Tools -- Other Tools Related to Quality -- Choosing an Off-the-Shelf Tool -- Implementing Tools -- Experimenting with Tools -- Project Tune-Ups -- Office Space -- Accessorizing for XP -- Metrics -- Test Environment -- Other Obvious Best Practices -- Additional Tester Duties -- Introducing XP to Your Organization: A Tester's Point of View -- Test Phases and Practices -- Introducing People to the XP Tester Role -- Helping XP Testers Succeed -- XP Testing with Blended Practices -- What If You Don't Have Enough Testers? -- XP for Projects of Unusual Size -- Adjusting XP -- Advance Planning Pays Off -- Working with Customers -- Satisfying Customer Test Documentation Requirements -- Iteration Planning and Execution for Large or Multilocation Projects -- Extreme Testing without Extreme Programming -- Gathering Requirements -- System Design -- Planning and Defining Tests -- Running Tests -- Retrospectives -- Let Worry Be Your Guide.

Testing is a cornerstone of XP, as tests are written for every piece of code before it is programmed. This workbook helps testers learn XP, and XP devotees learn testing. This new book defines how an XP tester can optimally contribute to a project, including what testers should do, when they should do it, and how they should do it.

There are no comments on this title.

to post a comment.
  • Monday - Friday
  • 8:00 AM - 5:00 PM
  • Saturday - Sunday
  • Closed
  • Phone: +971 431 83183
  • Email: Library@aud.edu
  • Address: Sheikh Zayed Road -- P.O. Box 28282, Dubai, AE
  • Map & Directions