Testing Plan

Unit Test Strategy:

• These tests will cover the functions in each class, with a set of tests corresponding to each function.
• Each developer will be responsible for creating their own unit tests for their own modules.
  Each developer must first create a paper test plan (due 4/28), which will be reviewed by the other developers. After reviewing and editing, the unit tests will be coded (due 5/1). At this point, all unit tests will fail.
• Unit tests should be run every time before code is committed. Developers must run the unit tests for their own modules, as well as any other modules they may have edited.

System Test Strategy:

• These tests will cover interactions between different modules, with a set of tests for every interaction (function calls, etc.)
• Each developer will be responsible for creating tests for any interactions in which their module calls upon functionality of another module.These tests should be written as prototypes, and then reviewed by the developers for both modules, and finally coded up. All integration tests should pass by the point of beta release (estimated 5/13).
• System tests should be run every time code is committed. Tests should be run for all interactions involving modules that have been modified.

Usability Test Strategy:

• These tests will cover the user experience aspects of the application, designed to determine what areas in our application cause confusion or an excessive amount of work for our users.
• Usability tests will be developed as a group and should be developed before user studies and beta release. Tests should be designed as a set of tasks for a user to do that cover all the primary functionality of the application.
• Usability tests will be run through user studies, which should occur at the time of beta release, and at the time before final release. Developers should also try to complete the usability tests to serve as a good gauge for the usability in between studies.