COEN 286: Software Quality Assurance and Testing -- fall, 2001

Software Test Exercise

Prof. John Noll

Santa Clara University

Mon Oct 8 16:07:38 2001


Due Monday, October 8, at the beginning of class.

1. Introduction

It's one thing to talk about testing and various test techniques, and another to actually do it. The intent of this exercise is to provide first-hand experience with the problems of testing a given software product.

Your task is to design and perform tests on the Budget Program from last winter's Object Oriented Design and Analysis course.

2. Instructions

You must perform this exercise (at least in part) on a host with John Ousterhout's tclsh installed. The SCU Design Center servers ({hpux,sol,linux}.dc.engr.scu.edu) meet this requirement (run setup tktcl after you log in to add tclsh to your path).

The Budget program is a TCL script that reads a budget specification from stdin and prints the resulting budget to stdout. Your job is to spend some time testing this program.

Invoke the program as follows:


% tclsh budget.tcl < budget-file

The format of budget-file is described in the original project specification

Do the following:

  1. Copy the budget program script and sample input file to your home directory.
  2. Test your environment to be sure you can run the program. On a Design Center server, you can do this as follows (login to one of {hpux,sol,linux}.dc.engr.scu.edu):

     % setup tktcl
     % tclsh budget.tcl < budget-example.dat 
     
    

    The script should print a twelve-month budget.
  3. Design a series of tests, using the project specification as a guide. There should be enough tests for three hours of testing.
  4. Implement your tests. For the most part, this will comprise writing input files that test various features of the budget program.
  5. Spend exactly three hours testing the program, using the tests implemented above. Record each failure uncovered, the test that produced it, and how the failure deviated from expected behavior. You may split the actual testing phase into smaller sessions, but each session should be at least one hour.
  6. Document your results according to the format described below.

3. Deliverables

Submit a printed (hardcopy) report enumerating the following:

  1. A cover page including your name, student id, the name of this course, and the date.
  2. A list of the tests performed. Number the tests starting at one (1), give each test a short descriptive name, and include a description of the test including setup (if other than a normal initial environment is required), inputs, and expected output.
  3. A list of failures observed. Number the failures starting at one (1), and give each a short descriptive name. Identify the test that produced the failure, and describe how the actual observed behavior deviated from the expected behavior.

In addition to the requirements enumerated above, be sure to read a follow the Quality Standards described on the Course Information page.

If for some reason you cannot attend class on the due date, notify me via email ahead of time, and submit your results via email as in-line plain ASCII text in Unix format, or a PDF attachment (do NOT send Word doc files or other formats). When printed, your attachment must conform to the requirements listed above.