1 / 14

Criteria-Based Test Case Design

Criteria-Based Test Case Design. Tracy Monteith (who is here because he lost a bet with Tom). What does…. Criteria-based mean to you? Test Case design mean to you?. What I intend to speak about. Discuss Test Case organizational Techniques Discuss Test Case design approaches

borka
Télécharger la présentation

Criteria-Based Test Case Design

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. Criteria-Based Test Case Design Tracy Monteith (who is here because he lost a bet with Tom)

  2. What does… • Criteria-based mean to you? • Test Case design mean to you?

  3. What I intend to speak about • Discuss Test Case organizational Techniques • Discuss Test Case design approaches • Discuss criteria used to determine which test case design techniques I should use. Not covered: Type of software, type of industry, criticality of software, organization maturity, timeline, company specific techniques, size of effort, manual vs. automation, capacity of test team, recent weather trends

  4. Test Case Organization • Test Type • Quality Criteria • Work Breakdown Structure

  5. What type of Organizational Schemas Do You Use?

  6. Now that you have the right buckets… • How do you decide which type of test design techniques will serve you best? • What type of information is available to the test designer and when?

  7. Input = Requirements • Are they explicit or implicit? • Are they enumerated and prioritized? • What is the source of the requirements? • Have the requirements been verified? • Reasonably Complete? • End-User Requirements vs. Stakeholder Requirements TC = Stepwise Requirement Hierarchy

  8. Input = Code • Code == Spec (a developer’s dream) • What language? • What is the Quality of the Code? • Is this legacy or new code? • TC = structure testing methods combined with derived functionality test

  9. Input = Functional Specifications • How complete? How confident? • New software or legacy extension? • Cross-referenced with other FunSpecs? • TC = Hierarchical functionality

  10. Input = Design Specification • Do you have access at Design time? • Are designs kept reasonably current? • How much of total system has explicit design specifications? • TC = Model-based Testing

  11. Input = User Scenarios (Use Cases) • How Complete? • Stripes of users and patterns? • Temporal constraints? • User environment information? • TC = User-based scenario e2e

  12. My Personal Favorite • WBS x Quality Criteria x Test Type • With a judicious use of test techniques

  13. Good Ideas • Combine techniques when multiple information avenues are available • Use Test Case templates for all test cases • Also provide the perfect “example” test case • Don’t mix purpose of Test Case • Write Test Design Specification BEFORE writing test cases • Use list on next slide to evaluate test cases

  14. How do you recognize a good test case? • A test case must be: • Clear of purpose • Well organized • Reviewable • Maintainable • Complete • Re-usable • Useful to other testers • Easily Scheduled • Efficient

More Related