From Use Cases to Test Cases


  • From Use Cases to Test Cases
    • The tester perspective
    • Testing terms
    • Test cases from use cases
    • Black Box vs. White Box testing
    A Tester’s Perspective:
    • Traditionally Testers come late in development process,
    they see the system as a black box because they know
    little about it.
    They may ask the following
    • What is the system supposed to do and in what order?
    • What are the things that may go wrong?
    • How can we create test scenarios?
    • How could I know that the system is tested completely?
    • Anything else about the system?
    • Is there a way to start testing earlier?
    (Not Recommended)
    A Tester’s Perspective:
    • This will be different if we have use cases.
    Testers will perform testing based on:
    1. Comprehensive use case model showing how
    the system behave, actors, and system-user
    Interaction.
    2. Each use case has typical and alternative flow
    of events, pre-conditions, post-conditions
    3. Supplementary nonfunctional requirements
    Deriving Test-Cases
    Use case = Test case ??
    • Not really.
    • We still need to make a lot of analysis to
    derive test cases from the use cases.
    Common Testing Terms
    • Test case: set of test inputs, execution
    conditions and expected results developed for a
    particular objective
    • Test Procedure: set of detailed instructions for
    the setup, execution, and evaluation of results
    for a given test case.
    • Test coverage: defines the degree to which a
    given test or a set of tests, address all specified
    test cases for a given system or component.
    • Test item: A build that is an object of
    testing.
    • Test results: Set of data captured during
    the execution of a test.
    Common Testing Terms
    Relationships of test artifacts
    The role of Test-cases
    • Test cases form the foundation to design
    and develop test procedure.
    • Depth of testing is proportional to the
    number of test cases (when designed properly)
    • Scale of test effort is proportional to the
    number of test cases
    • Test design, development and resources
    are governed by the test cases
    Use-Case Scenarios
    • A scenario is an instance of a use case
    • Execution of a use case, wherein a
    specific user executes it in a specific way.
    Use case scenarios
    Deriving Test-Cases from Use-Cases
    A Four Step Process:
    • Identify the use case scenarios.
    • For each scenario, identify one or more
    test cases.
    • For each test case, identify the conditions
    that will cause it to execute.
    • Complete the test case by adding data
    values
    Step-1 Identify the use case scenarios
    • Use simple matrix that can be implemented in a
    spreadsheet, database or test management tool.
    • Number the scenarios and define the combinations of
    basic and alternative flows that leads to them.
    • Many scenarios are possible for one use case.
    • Not all scenarios may be documented. Use an iterative
    process.
    • Not all documented scenarios may be tested.
    • Use cases may be at a level that is insufficient for
    testing.
    • Team’s review process may discover additional
    scenarios.
    Step 2- Identify the test cases
    Parameters of a test case:
    • Conditions
    • Input (data values)
    • Expected result
    • Actual result
    Step 3-Identify the test conditions
    • For each test case identify the conditions that
    will cause it to execute a specific events.
    1. Use matrix with columns for the conditions and
    for each condition state whether it is
    • Valid (V): Must be true for the basic flow to
    execute.
    • Invalid (I): This will invoke an alternative flow
    • Not applicable (N/A): To the test case
    Step 4-Add data values
    • Design real input data values that will
    make such conditions to be valid or invalid
    and hence the scenarios to happen.
    • You may want to look at the use case
    constructs and branches.
    Managing test Coverage
    • Select the most appropriate or critical use
    cases for the most thorough testing.
    • Choose the use cases based on a balance
    between the cost, risk, and necessity of
    verifying the use case.
    • Determine the relative importance of your
    use cases by using a priority algorithm.
    Key Points
    • It builds a set of assets that can be used to
    derive the testing process.
    • Use cases can directly derive or seed the
    development of test cases.
    • The scenarios of a use case create templates for
    individual test cases.
    • Adding data values completes the test cases
    • Testing non-functional requirements completes
    the testing process.
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s