Theoretical Approach:

The theoretical approach will ensure that you have good comprehensive documents for the system at the end of the process.

What are Use Cases:

Use case is a description of the interaction between the user and the system. This can also be described as a way of using specific part of application’s functionality. A

complete collection of use cases describes all the ways that a user can manipulate a

software system.Use cases are a very powerful method of describing requirements.

They form basis for

Software Design
Test Cases
User documentation
GUI design

Use cases are written during the requirement phase of the software project. Use cases are written in a plain English language that user can easily understand. Business analysts that have been specially trained to develop use cases should write them. Rational Rose is a tool that can be effectively used to model and also write use cases. However most use cases are written in MSWord as everyone can easily access them.

Use Case Based Approach

Traditionally use cases have been used for requirement gathering. There has been a considerable shift to use them for testing, primarily because they model user role-play, movement, access rights and the interaction of one module to another – which is essentially what a test plan aims to do.

A use case defines the following –

1. Primary actor or actors

2. Goal

3. Scenarios used

4. Conditions under which a scenario occurs

5. Scenario result (goal delivery or failure)

6. Alternative scenarios or flows

The advantage of this approach is that you have two ready things in your hand

1. Documented system functionality

2. Evident module interaction

The development or creation of the use case will not be an easy task. Typical way to develop a use case is to pick up the system screen by screen or module wise and talk to the concerned developers or business analysts. Users can also be brought into the discussion at a later stage. Most users will give you valuable inputs to the type of data they input to the system. That in turn can give you an insight to the flows of the system.

Exemplary questions that you can ask users/developers are:

1. Inputs to a screen

2. User movements/warnings on a screen

3. Access rights to screen(s) or modules.

4. Access to screen(s) and exits from screen(s)

5. Database checks/updates.

6. Outputs from a screen

7. Alternative inputs or exits from the screen(s).

You can screen these questions or add some based on the testing you will be conducting for the system. For e.g. If you are carrying out GUI testing, you could do well if you add questions like length of the text box (this question could be answered well by a developer, rather than a user or a business analyst). If you are doing system testing, you could probably cut out the question on database check or updates. On the other hand, if you are doing system testing as part of a technology migration, you should enforce that database updates are verified.

Programming Portal

Top Tabs

WRITING SOFTWARE TEST CASES PART TWO

Theoretical Approach:

Use Case Based Approach

No comments:

Post a Comment