Steps To List Functional Testcases

I The derivation of Functional test cases and the mapping between them & the usecases
Needs -> Features -> Usecases/Support Specs -> Scenarios -> Testcases
II The use case mostly will list/have the following details
Brief description
Flow of events
Basic flow
Alternative flow 1
Alternative flow 2
Special requirements
Preconditions
Post-conditions
Extension points
Context diagram
Activity diagram

III To List the Scenarios [Step by Step Process]
Select a basic flow, one scenario covering each alternative flow, and some reasonable combinations of alternative flows.
For a flow where a loop is encountered it is enough to do the basic flow once, do a loop once, and then do a loop a second time. If the program works for both instances of the loop, it can be assumed that it will work for all of them
IV Traceability from use cases to scenarios
V Listing TestCases
Identify variables for each use case step
Identify significantly different options for each variable
Combine options to be tested into test cases
Assign values to variables

1. Identify variables for each use case step
1. Identify all input variables in all of the steps in the given scenario
2. The variable can also be a selection that the user can make (Save changes or Cancel).
2. Identify significantly different options for each variable
Significantly different options, trigger different system behavior. Also, an option can be considered significantly different if the following are satisfied
It triggers different flow of the process (usually an alternative flow)
Example
o Entering invalid password will trigger Alternative Flow 2
It triggers different error message
Example
If email is to long, the message is "Email should have no more than 50 characters"
If email does not contain @ sign, the message is: "Invalid email address"
It causes different appearance of the user interface
Example
If Customer Property is set to 2.0, the app for 2.0 is shown
It causes different selection to be available in the drop-downs
Example
The customer registration screen may contain drop-downs "Country" and "State/Province". The drop-down "State/Province" is populated based on the country selected: for the US it contains all the states, for Canada all the provinces, and for other countries it is grayed-out. This creates three different options:
US
Canada
Any other country
It is an input to some business rule
Example
Assuming there is a rule "If the duration to generate reports is more than 7 months and user selects list reports, the message should inform that the duration can only be less than 7 months, we may have two separate options:
List reports for duration less than 7 months
List reports for duration greater than 7 months
It is a border condition
Example
Since password should have at least 6 characters we should test:
Password with 5 characters
Password with 6 characters
Something is changed vs. the default is used
Example
On the force change password section, the county is displayed as US by default. This creates two separate options:
Keep default country
Change country to a different one
The entry format is not clearly defined and may be differently interpreted by the user
Example
Phone numbers are written differently by different people:
Using brackets (973) 123 4567
Using dashes 973-123-4567
Plain number with spaces 973 123 4567
When regular cases differ in different countries
Example
User expiration date format may be different in the USA and in Europe
If we are testing numbers, we may consider the following options:
o Regular number, reasonable from the application point of view
o Zero
o Negative number
o A number with two decimals
o The biggest number that can be entered (99999999999999 - as many nines as can fit)
3. Combine options to be tested into test cases
The options should be combined in the sequence of test case steps
4. Assign values to variables
1. Replace Placeholders with actual/sample data/values
2. Create a persistent Dataset
VI Traceablity from Scenarios to TestCases [DataSet to an extent]
VII Benefits
o Test cases are derived in a more automatic way
o Avoids duplicate testing
o Better test coverage
o Easier monitoring of testing progress
o Easier work load balancing between testers
o Easier regression testing
o Contributes to early discovery of missing requirements
VIII Configuration Plan/Version Control