Chapter2...continue

Example - Microsoft Word

TEST NO <\t>INPUTS <\t> EXPECTED RESULTS
1 <\t> Click on File hold down and Drag to Open <\t>Open dialog appears

2 <\t> Right click on paragraph <\t> Menu options appear - font, paragraph etc.
Cut Copy Paste are grayed out
3 <\t> Right click within a table <\t> 12 menu options appear related to table
Actions e.g. insert row, delete row
4 <\t> Spelling <\t> Spelling checking starts and displays first Error but check grammar off (Depends on option)
5 <\t> File Print <\t> Displays printer dialog
6 <\t> Click on print icon <\t> Will attempt to print to default printer

Driving License Exercise


Consider the following simple program:

IF age> 16 and age <=65 THEN
Issue drivers License
IF age <26 THEN
Set Insurance Premium to HIGH
ELSE
Set Insurance Premium to STANDARD
END IF
ELSE
Error message DLOOl -" Sorry, unable to issue drivers license"
END IF


TESTNO INPUTS EXPECTED RESULTS
1 10
2 16
3 17
4 25
5 26
6 65
7 70





ATM Exercise
Some simplified rules for an A TM:
a) Card must be valid for this bank
b) Correct PIN must be entered
c) Withdrawal must not take account overdrawn unless there is an overdraft agreed
d) Notes available are £ 1 0 and £20 only

TESTNO INPUTS EXPECTED RESULTS
1 Valid Card
Incorrect PIN
£50 requested '"
2 Valid Card
Correct PIN
£200 requested
Balance £50
No overdraft 'i-
3 Valid Card
Correct PIN
£50 requested
Balance £50
No overdraft /
4 Valid Card
Correct PIN
£50 requested
Balance £400
Withdrawn £160 earlier 1-

Telephones Exercise

TEST NO INPUTS EXPECTED RESULTS
1 Pick UD receiver
2 Dial 100
3 Dia1142 or 192
4 Dial 999
5 Dial Busy Number
6 Press5 After Hearing Engaged tone
7 Dia11471
8 Dia11571



1. 9 Prioritization of Tests

Since we have discussed already that there is never enough time to do all of the testing that you would like an obvious approach is to prioritize the tests This will then mean that whenever you stop testing you will have done the best testing possible in the time available.

The test manager should identify the criteria to hi used when prioritizing tests. These will include but are not limited to:

 Severity.
 Probability.
 Visibility of failure.
 Business priority assigned to the requirement.
 Customer wants.
 How much change the function has undergone.
 How error prone is this module.
 How critical is it to the business.
 How technically complex is it.
 How difficult is it to test.
 How costly is it to test.

Keep the test priority with the test at all times. This_ will prevent you from developing and designing lo_ priority tests that never get run. Use a scheme of high, medium, low or a numeric scheme or 1,2, 3, 4 but try not to have more than about 4 categories.

NO TEST CASE DESCRIPTION
1 A manual block on a bank is introduced (using the HOLD function)
Causing payments to be moved between priority classes by the
Scheduler
2 Failure of the primary scheduler process
3 Internal authentication failures
4 Normal close of day
5 Normal system start up
6 One of each type of request to the scheduler
7 Payments are released correctly from the USER class when limits
Exceeded but funds received from another bank causing position to
Improve
8 Payments can be routed to the scheduler queue from several sources
with the correct class and user defined priority (including payments
that have been referred or repaired)
9 Payments cancelled manually be central control
10 Regression testing of existing telecommunications links
11 Regression testing of recompiled interface with mainframe system
12 Remote bank changes their limit on us causing payments to be
Released from the USER class (if held due to exceeding limit)
13 Remote bank issues temporary raise
14 Route all payments to the scheduler with parameters set for
immediate release
15 Special processing when internal cut-off time reached
16 Suspend/activate limits
17 Suspend/activate scheduler


You should now be familiar with some of the fundamental principles of testing and you will recognize much of the terminology. The horror stories that you will have heard are not just sensationalist to motivate the course; they are true stories and there are (unfortunately) many more stories about the costs of not testing systems properly.

In particular you can now:

 Recognize and use basic testing terminology.
 Understand why testing is necessary.
 Define error, fault and failure.
 Explain why errors occur.
 Give examples of the cost of errors.
 Understand why exhaustive testing is unachievable.
 Appreciate why testing is a risk management process.
 Understand the fundamental test process.
 Understand the difference between the mindsets of developers and testers.
 Understand why you cannot test your own work.
 Understand the need for regression testing.
 Understand the importance of specifying your expected result in advance.
 List some criteria for prioritizing your tests.