Test Plan (created by Eric)

One of our chief concerns is memory errors or any exceptions that will halt the program and destroy a user's unsaved data. We plan to include testing with the ‘purify’ utility to find any memory access violations encountered when we run and use the program.

Of course, we must determine which program inputs and which usage patterns are exhaustive enough to give us confidence in its stability. Additionally, we must check that certain user actions that are not defined are handled or disabled at the appropriate time.

One idea is to abstract the program's execution into the states of a finite state machine, and view the GUI operations as transitions between states. With many possible actions at each state, it would be hard to make a complete diagram. But we can follow expected paths between states, and otherwise test lots of actions we expect to cause error messages, or act as no-ops. One of our group members is going to start doing this exclusively, and notify the entire group of any inconsistencies.

Here's an example of a state diagram we may try to use; the actions not included as transitions from a state are mostly errors or no-ops:
 
 

 

 

 

 

Another important concern is whether our product works as the client expects. We are going to try to demo several "drafts" of the program to our client, and see if any last minute revisions can be done to keep the product consistent with the client's expectations.