1 / 16

Acceptance Testing

Acceptance Testing. CSSE 376, Software Quality Assurance Rose-Hulman Institute of Technology March 30, 2007. Outline. Role of Acceptance Testing Other Paths to Acceptance Agile Approach. Requirements. High-level Design. Low-level Design. Code. Unit Testing. Integration Testing.

tsanford
Télécharger la présentation

Acceptance Testing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Acceptance Testing CSSE 376, Software Quality Assurance Rose-Hulman Institute of Technology March 30, 2007

  2. Outline • Role of Acceptance Testing • Other Paths to Acceptance • Agile Approach

  3. Requirements High-level Design Low-level Design Code Unit Testing Integration Testing System Testing Acceptance Testing Lifecycle Testing Relationships

  4. Requirements as Use Cases • For each use case enumerate a set of scenarios • Construct a test case for each scenario • Construct a test suite to run the test cases

  5. Other Paths to Acceptance • Beta testing • Distribute system to volunteers • Collect change requests, fix, redistribute • Collect statistics on beta use • Shadowing • Collect or redistribute real-time use of existing system • Compare results • Collect statistics

  6. Agile Approach: Framework for Integrated Test (FIT) • Developed by Ward Cunningham as an extension of xUnit framework • Encourages customer participation via simple tables

  7. Story-Driven Development • Customers write stories • Developers develop code to realize each story • Customers and developers work together to create tests of each story

  8. Cartoon of the Day

  9. FIT + Wiki + Web Server = FitNesse

  10. Why Do We Need a Wiki? • Lower the barrier to customer participation • Easy to keep up-to-date

  11. Fixture: Connection Between Test System and Application • When "Test" button is pushed a fixture is called to process the table • The fixture delegates to underlying application code • Fixture code is like xUnit TestCase code • extends base class • may create objects for multiple tests

  12. Common Table Formats • ColumnFixture • each row specifies one input and one output • RowFixture • first row is input, remaining rows are output • ActionFixture • each row is either an action to perform or a value to check

  13. ColumnFixture

  14. RowFixture

  15. ActionFixture

  16. Demo

More Related