IBM Software Group - StickyMinds · Jim Heumann Jim Heumann is a Requirements Management Evangelist...

BIOPRESENTATION

International Conference OnSoftware Testing Analysis & Review

November 15-19, 2004Anaheim, CA USA

F2

November 19, 2004 10 AM

WRITING TESTABLE USE CASES

Jim HeumannIBM Rational Software

Jim Heumann Jim Heumann is a Requirements Management Evangelist for IBM Rational Software. Throughout his twenty two year career as a software designer, developer, maintainer, consultant and manager he as been able to experience, first-hand, most of the challenges we all face day-to-day as software professionals. He has worked on projects in artificial intelligence, fraud detection in cellular phone usage, user interface design, visual data analysis, currency trading and wind profilers, to name a few. Jim has delivered over one hundred workshops, tutorials, training classes and conference presentations over the last ten years on a variety of subjects including Using Use Cases to Generate Test Cases, Requirements Management with Use Cases, Object Oriented Analysis and Design, Visual Data Analysis, and UML, among others. As his job title suggests, his primary role is to promote and educate on the importance of good requirements management. He holds an MS in Management Information Systems from the University of Arizona (USA).

IBM Software Group

®

Writing Testable Use Cases Jim HeumannRequirements Evangelist

Jim HeumannRequirements Management Evangelist

IBM Software Group | Rational software

Copyright © 2002 Rational Software, all rights reserved

2

Agenda / Learning Objectives

Short introduction: requirements and use cases

Writing use cases with testability in mindStyleContent

Using use cases to create test cases

Conclusion



3

Design ConstraintsOperating systemsEnvironmentsCompatibilityApplication standards

There Can Be Lots of Types of Requirements

FURPSFunctionalityUsabilityReliabilityPerformanceSupportability

Legal and Regulatory requirementsFederal Communication CommissionFood and Drug AdministrationDepartment of Defense



4

What is a Use Case?

Use cases are described in text

Register for CoursesStudent

Use cases are shown in UML diagrams



5

Use Case Textual Specification

A use case describes a sequence of actions a system performs that yields an observable result of value to a particular actor

The UML does not specify how the text of a use case should be structured, organized or writtenHow you write use cases will have a large impact on how easy they are to test (or not)



6

Use Case Style

Use cases can be considered "structured text"How you structure the text is the use case "style"

Style issuesDoes the main flow reference other flows or not?Do steps in the flows have numbers or titles or both?Do alternative flows have numbers or titles or both?How do you reference one part of a use case from another?Can flows have embedded flows?How do alternative flows tell what happens when they are done done?

The style affects testability



7

Outline of a RUP Style Use Case

One Basic FlowHappy-Day Scenario

Many Alternative FlowsRegular variantsOdd casesExceptional (error) flows



8

RUP Style Main Flow of Events

Structure the flow into steps

Number andtitle each step

Describe steps (1-3 sentences)

Don’t refer to alternative flows in the main flow



9

RUP Style Alternative Flows

1 - Say in which step or alternate flow the flow starts

Register For Courses Use Case

2 - Say what causes the flow to start

3 - Say what happens

4 - Say where the flow resumes

Alternative flows should deal with one condition



10

Style - Principles for Testability

One main flow with stepsMultiple alternative flowsSteps must be reference-ableFlows must be reference-ableAlternative flows should have the four partsNo goto's

Use a consistent style in all use cases for a given project



11

Use Case Content

Content refers to how the steps and flows are written

Content issues:ConditionalsMultiple conditions per flow or stepAmbiguous termsMissing stepsMissing flowsQuality of writing

The content affects testability



12

Conditionals And Multiple ConditionsWatch for If-statements

Watch for and's & or's



13

Content - Principles for Testability

Define ambiguous terms in a glossary

Review use cases for missing flows/steps

Write well

Limit if-statements

Discourage embedded flows

Try for one condition per step or flow



14

Use Case Anti-Example



15

Use Case and Test Cases

There is a straightforward way to produce test cases based on use cases

Benefits of creating test cases from use cases:Allows testers to write test cases before any code is writtenProvides a clear testing methodologyGives testers a head start understanding what the application issupposed to do



16

What is a Test Case?

An "intermediate artifact"

Helps organize and develop Test Scripts and drivers (manual and automated)

A Test Case answers the question: "What is it that I need to test?"

Test cases prove that the actor can get the value that the use case specifies

A set of test inputs, execution conditions, and expected results(outputs) developed … to verify compliance with a specific requirement

Rational Unified Process

Test CaseTest Case



17

Deriving Test Cases from Use Cases

Step oneIdentify all paths in a use case - scenarios

Step twoFor each scenario create a test case and identify the conditionsin the use case that would cause it to execute

Step threeReview and reconcileAdd data values for the conditions in the test cases



18

Scenarios - Paths Through a Use Case

Scenarios describe each set of unique interactions between the actor and the system, start to finish, through the use case

You can't test alternate flows by themselves

A good (testable) use case allows you to define a complete set of scenarios



19

Each possible combination of main flow and alternate flow(s) will identify the full set of scenarios

When finding scenarios It is useful to draw a pictureUML activity diagramA picture like this

Finding Scenarios



20

Finding Scenarios Register For Courses Use Case

Look for references in the alternative flows



21

Scenario Matrix - Register for Courses

Note: This matrix is not

complete

Use a scenario matrix to keep track of scenarios



22



Step twoFor each scenario, create a test case, and identify the conditions in the use case that would cause it to execute




23

Scenarios to Test CasesCreate a test case matrix

For each scenario add a row (a new test case) in the matrix

Identify conditions to test - study the use case flows of events• Look for things the user does (e.g., quit)• Look for data input by users (e.g., password)• Look for data provided by "the system" (e.g., courses)• Look for things the system does (e.g., check for course full)

For each condition add a column in the test case matrix

For each test caseIdentify whether each condition will be valid or invalid Identify the expected result of executing the scenario



24

Finding Conditions and Expected Results



25

Example Test Case Matrix - Register for Courses

Each row is a

test case



26

Test Case Matrix - Observations

No actual values were entered for the conditions

It is easy to see what conditions are being tested

It is easy to determine sufficient test coverage

If there is no I in a row, then a condition (column) is missing

If there is no I in a column then, a test case is missing



27



Step twoFor each scenario create a test case and identify the conditionsin the use case that would cause it to execute




28

Example Test Case Matrix - With Values



29

Writing Testable Use CasesHow you write use cases affects their testability

The style determines how well a use case "hangs together"

Content determines understandability and usability by stakeholders and testers

Consistency across the team is important

Creating test cases based on use cases has these advantages:Allows testers to write test cases before any code is writtenProvides a clear testing methodologyGives testers a head start understanding what the application issupposed to do



30

For More Information

Rational Unified ProcessRequirements disciplineTest Discipline - Guideline: test case

IBM DeveloperWorks (www.developerworks.com/rational)

Use Case Modeling, Bittner and Spence, Addison-Wesley, 2003.

Managing Software Requirements: A Use Case Approach, Leffingwelland Widrig, Addison Wesley Professional, 2003

IBM Software Group - StickyMinds · Jim Heumann Jim Heumann is a Requirements Management Evangelist...

Documents

Transcript of IBM Software Group - StickyMinds · Jim Heumann Jim Heumann is a Requirements Management Evangelist...