the deltaTraffic weblog

Over at extreme testing, a good article on test cases.

What values do you input to your program?

Since errors tend to happen around the boundaries of predicates, you write test cases for those boundaries. So if you have a range of 0 to 999 you opt for -1 and 1000, with valid tests being 0 and 999. Everything in between being immaterial.

Here are some exam questions asking for test cases in three different scenarios:

1. Consider a program that accepts the age of a person as input and computes the amount of premium s/he has to pay for a medical policy. Describe your design of test cases for testing the program. (Note: Assume that the age of babies before their first birthday to be one year).




2. You have been asked to test one of the modules in a software system that supports of an e-commerce website. This module processes credit card details supplied customer credit card number, card type (Master/Visa), ‘Valid From’ date and parameters. If the card is valid for the date of the transaction, then this module transmitted to CyberCash to process payment from customer to merchant.




3. Consider a program that accepts the speed of a car in MPH (miles per hour) as input and displays an estimated stopping distance somewhat similar to the figures mentioned in the Highway Code. Write test cases for testing this program, stating clearly (i) the procedure you would use for designing test cases and (ii) any assumptions you make.

Hmm, great. What does a test case look like? The chaps at cam have a good idea.

And whats this? a Test Case Format? Ahh, yes. Another shows what a test case ought to be plus other notes on what types of black box testing there are out there.

“test case: A set of inputs, execution preconditions, and expected outcomes developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement. After [IEEE,do178b] ”
from here

inputs:
preconditions / assumptions:
expected result: