Computer Science 121 - Project 2d

Test Plan

Fall 2007

$Id: proj_2d.m4 141 2007-11-12 21:47:43Z Mark $

Critical Dates

Project Description

  1. Introduction
  2. Deliverables Table
  3. Assignement Details
  4. Grading
  5. Rules and Submission

1. Introduction

Specifications and designs are the most commonly used basis for test plans. You have specified and designed a GKrellM plug-in, and now you will need to define a testing plan to assess/ensure the correctness of an implmentation.

This phase will complement the materials presented in the lectures on:

The primary goal of this project phase is to give you actual experience with:

  1. evaluating specifications to identify a reasonable set of functional acceptance tests.
  2. evaluating a design to identify additional, meaningful white-box test cases that will significantly enhance our confidence.
  3. evaluating a design to identify error conditions whose handling should be tested.
  4. integrating a testing strategy into a design.
  5. writing test case specifications to be reviewed and implemented by others.

2. Deliverables

The graded deliverables for this project are summarized in the following table. They are described in greater detail in the assignment descriptions and grading criteria.

Type Basis Description Value
team work product Index of Work Products 1
team work product Test Plan 35
team work product Post Mortem Analysis 8
team methodology Use of Version Control 1
team work product Plan for phase activities 2
team methodology Planning and Management 2

3. Assignment

For this phase you will:

  1. figure out (if you did not already do so in phase 1) how you will organize and divide this effort, and specific due dates for individual activities and work-products.
  2. review the module specifications, and define a reasonable set of functional acceptance tests for your plug-in.
  3. identify likely error conditions, define additional test cases to give us confidence that these errors will be properly detected and reasonably handled.
  4. review the detailed design, and define additional white-box test cases to give us confidence about mechanisms that are not thoroughly exercised by the black-box test cases in (2 above).
  5. define a strategy and framework for automating all of the above test cases.
  6. if, in the process of defining the above, you find it necessary to change your design, make the necessary changes, and discuss them in the post-mortem.
  7. write specifications and a detailed design for the framework to be used to run these tests.

    Pay special attention to any dummy modules you might need to build in order to perform the described testing.

    If you are using a standard framework (e.g. CUnit), you do not have to describe the framework, but merely how you will integrate these tests into it.

  8. write specifications for all required test cases.
  9. conduct a post-mortem of this process, and write up a report of that review.

4. Grading

Each phase of this project will receive a team grade. Individual grades (for contribution, quality, and schedule management) will be based on the combined deliverables for all of the phases.

4.1 General Criteria

This project requires the same general project index, plans, subversion use, and post-mortems that are part of every project in this class.

An overall project plan will have been created in the first phase, but (if it has not yet already been prepared) you will also need to prepare a detailed plan for how the sub-tasks of this phase will be done, by whom, and on what dates.

The team will be graded, as a whole, on its ability to

  1. Perform the work according to the plan.
    We will determine when work was done by looking at the dates of the final subversion check-ins.
  2. Monitor progress and detect problems.
    Monitoring plans should be included in your project plan. Problems that come up should be discussed in your post-mortem.
  3. Reasonably adjust the plan in response to problems.
    Detected problems and responses should be discussed in your post-mortem, and reflected in revisions to the plan.

Individuals will be graded on the extent to which they were able to perform their work according to (a) the original plan or (b) the plan of record.

4.2 Project Specific Grade-ables

The project specific grade-ables for this project are:

4.3 Work Product Formats

The standard guidelines for work product formats apply.

5. Rules and Submissions

When you are done, create a message that includes:

And submit all of these things to me in an e-mail with the subject "cs 121 - Project 2d".

If you will be submitting your project late, please let me know (so that I know I haven't lost your submission message).

Collaboration and Citation

This is a team project, but different individuals will have primary responsibility for different processes or work products (or different parts of a single work product or process). Each team will be working on a different type of product. You are free to talk your team members (and for that matter other teams) about the processes you are following. You may review your work products with your own team members, and revise them based on their feedback ... but ...

  1. If you are the primary author of a work-product, you must cite the source of text you did not write (if it is more than a sentence), or any information that did not originate within your team or from your interviews.

    You will be doing research to develop your product definition and requirements. I expect that many of the ideas for your product will come from this research. Cite all of your sources for each work product, and explain how each source contributed to your work products.

  2. You may not share any of your work products (other than as required for reviews) with members of other teams.