Test Plan

Stage 1: Module/Unit Tests

Test Supervisor: Russ Magee
Overall objective: This test plan is designed to verify that the Login Module performs the tasks required of it, as outlined in the Overall Design Document.

Test 1:

• Objective:
  Test login procedure.
• Inputs:
  Enter invalid name and ID. Enter valid name and invalid ID. Enter invalid name and valid ID.
• Expected Outputs:
  Alert box stating that an Invalid name and/or password was entered. If this was the third unsuccessful login attempt, program is terminated.
• Walkthrough:
  Click on the white text entry box labeled "Enter Employee ID". Type in the login name of an employee. Type in the password associated with the employee's login name. Click the "OK" button or hit from the password field to attempt login. Verify that only correct login name/password pairs allow entry into the system. Verify that only the Supervisor name/password pair gains access to 4. Employee Records Module. Verify that login aborts program after third unsuccessful login attempt.

Test Supervisor: Chris Mohr
Overall objective: These tests are to be done to make sure that all meetings are updated properly in the data stores, and the attendees are all updated in the booking table.

Test 1:

• Objective:
  This test will make sure that ALL automated meetings and the manual meetings that have been created will be written to database correctly and all messages sent everyone in the meeting.
• Inputs:
  Create several automated meetings.
  AUTO. 1. NAME: Test Meeting I DATE: Feb 10,1996 TIME: 11:00am
  TOPIC: This is a test. ROOM: 123
  Attending: Joe, Harry, Sally

  AUTO. 2. NAME: Test Meeting II DATE: Feb 12,1996 TIME: 11:00am
  TOPIC: This is a test. ROOM: 123
  Attending: Sarah, Joe, Bill

  MAN. 3. NAME: Test Meeting III DATE: May 12,1996 TIME: 1:00pm
  TOPIC: This is a test. ROOM: 123
  Attending: Joe, Sarah

  1. Joe login. Check message flag.
  2. Harry login. Check message flag.
  3. Sally login. Check message flag.
  4. Sarah login. Check message flag.
  5. Bill login. Check message flag.
  6. Henry login. Check message flag.

• Expected Outputs:
  Joe will have 3 new messages.
  Harry will have 1 new message.
  Sally will have 1 new message.
  Sarah will have 2 new message.
  Bill will have 1 new message.
  Henry will have no new messages.

  Joe, Harry, and Sally will all have a new message when they log in pertaining to the meeting:
  NAME: Test Meeting I DATE: Feb 10,1996 TIME: 11:00am
  TOPIC: This is a test. ROOM: 123
  Attending: Joe, Harry, Sally

  Sarah, Joe, and Bill will have a new message when they log in pertaining to the meeting:
  NAME: Test Meeting II DATE: Feb 12,1996 TIME: 11:00am
  TOPIC: This is a test. ROOM: 123
  Attending: Sarah, Joe, Bill

  Joe and Sarah will have a new message when they log in pertaining to the meeting:
  NAME: Test Meeting III DATE: May 12,1996 TIME: 1:00pm
  TOPIC: This is a test. ROOM: 123
  Attending: Joe, Sarah

Test Supervisor: Chris Mohr
Overall objective: These tests will show that when a user goes to view a certain meeting, it correctly chooses the appropriate meeting and displays ONLY the meeting info for that meeting.

Test 1:

• Objective:
  Will show proper viewing of a meeting.
• Inputs:
  Have meeting in database with very specific information. NAME: Test Meeting DATE: Feb 10,1996 TIME: 11:00am TOPIC: This is a test. ROOM: 123. Click on the meeting in the calendar viewing area.
• Expected Outputs:
  Meeting info is displayed showing only the following info: NAME: Test Meeting DATE: Feb 10,1996 TIME: 11:00am TOPIC: This is a test. ROOM: 123. All other fields blank.

• Objective:
  Will show proper viewing of a meeting making sure no carried over information is left from a previously view meeting.
• Inputs:
  Have meeting in database with very specific information. NAME: Do it Meeting DATE: Mar 13,1996 TIME: 2:00pm TOPIC: This is another test. Click on the meeting in the calendar viewing area.
• Expected Outputs:
  Meeting info is displayed showing only the following info: NAME: Doit Meeting DATE: Mar 13,1996 TIME: 2:00pm TOPIC: This is another test. All other fields blank. Make sure ROOM: 123 is NOT there!

• Objective:
  Will show that when an empty space is picked, nothing is in the meeting viewer.
• Inputs:
  Click on an empty space in the calendar viewing area.
• Expected Outputs:
  The viewing area is complete white space.

Test Supervisor: Chris Mohr
Overall objective: These tests will show that when a user wants to view all the meetings he/she has, the proper list will show up.

Test 1:

• Objective:
  Make sure when you load the form for a meeting the function keys appear.
• Inputs:
  Load this info for a meeting into the system under the load schedule section.
  AUTO.1. NAME: Test Meeting I DATE: Feb 10,1996 TIME:2:00pm
  TOPIC: This is a test. ROOM: 123
  Attending: Joe, Harry, Sally (everything is valid)
  
• Expected Outputs:
  The scheduler screen with all the functions displayed.

• Objective:
  Try a invalid date/start time and make sure it gives an error and prompts for re-entry.

Test Supervisor: Michael Cullingham
Overall objective: This module must select the correct meeting from the database and display the information in the appropriate text boxes/radio buttons/etc.

Test 1: Normal input.

• Objective:
  This will be a test when greater than or equal to one convened meeting is in the list box of convened meetings. The task will be successful if the program displays the correct meeting information.
• Inputs:
  Click on one of the meetings in the list. The meeting will be pre-defined to contain information similar to that information input during the testing of module 3.3.4 (test #1).
• Expected Outputs:
  The meeting information displayed should be that of the meeting defined in the module 3.3.4 test #1.

• Objective:
  This task will ensure that the program does not halt when the user clicks in the empty list. Technical Justification: This may not seem like a reasonable test, but when a list box is empty it will have a list index of -1. It is possible for the user to produce a click event on the list without highlighting any meeting. Without error checking to cover this, the system will attempt to gather information about the information in the -1 position of the list, which does not exist, and often will crash. (Although Delphi may foresee this.)
• Inputs:
  Produce "Click" event (or "Double-Click") on empty list box.
• Expected Outputs:
  The program should do nothing when this occurs, and should allow for the user to continue working in the program.

Test Supervisor: Chris Mohr
Overall objective: These tests will show that when a user wants to cancel a meeting, it makes sure it is canceled.

Test 1:

• Objective:
  Will show proper deletion of a message when the user clicks for the system to do so.
• Inputs:
  Make sure there is a valid meeting available. Meeting is clicked from the scheduled meetings. Click on "Cancel Meeting" button, then on "OK" button. Return to main, then check if meeting is still there.
• Expected Outputs:
  Meeting info is displayed. Then after "Cancel Meeting" and "OK" is clicked, meeting is no longer there.

• Objective:
  Make sure messages will not be deleted if "Cancel Meeting" was not clicked.
• Inputs:
  Make sure there are valid meetings. Meeting is clicked. Exit meeting sub-system, then re-enter...
• Expected Outputs:
  All meetings will still be there.

Test Supervisor: Michael Cullingham
Overall objective: These tests are designed to ensure that no error-ridden meetings can be written to the database, that employees are notified of being scheduled for a meeting or invited to a meeting they cannot attend, to ensure that the meetings appear in the timetables of the people attending, and to ensure that the meeting appears in the "convened meetings" list for the scheduler. For this discussion, the date is assumed to be March 17, 1996 at 1:00 pm.

Test 1: Normal input.

• Objective:
  This test will demonstrate that when all normal input is entered, the system will notify the user that the meeting was scheduled, write messages to all employees invited, and write the meeting to the database.
• Inputs:
  Topic: "Meeting Test 1a", Agenda: "A test meeting", Start Time: 3:00 pm, Duration: 1.5 hrs, Date: March 20, 1996, Employees Invited: Bob - can attend, Joe - can not attend, Elvis - can not attend, Dave - can attend, Location: Earth, Frequency:7 days.
• Expected Outputs:
  1. A message box should appear to announce the scheduling of the meeting.
  2. All 4 people invited should receive Messages informing them of the meeting and their status.
  3. Bob and Dave should have the meeting appear in their Time Table.
  4. Joe and Elvis should not have the meeting appear in their Time Table.
  5. The scheduler should have this meeting added to his list of convened meetings.

• Objective:
  This test demonstrates that a meeting in which no employees are scheduled to attend will not be written to the database.
• Inputs:
  All data as in Test 1, except: Test 2a) Employee List: Null.
• Expected Outputs:
  In each case, the program should immediately inform the user of the error that occurred and NOT write the meeting or bookings to the database.

• Objective:
  These tests demonstrate that meetings that are scheduled to occur in the past will not be written to the database.
• Inputs:
  All data as in Test 1, except:
  Test 3a) Start Date: March 19,95, Start Time: 2:00 pm.
  Test 3b) Start Date: February 17/96, Start Time: 2:00 pm.
  Test 3c) Start Date: March 17/96, Start Time: 12:00 pm.
• Expected Outputs:
  In each case, the program should immediately inform the user of the error that occurred and NOT write the meeting or bookings to the database.

Test Supervisor: Michael Cullingham
Overall objective:These tests are designed to ensure that when called, this module returns the names of those employees that can attend a meeting, and those that can't. When given a date/time that has already past, the program should notify the user of this error.

Test 1: Normal input

• Objective:
  Demonstrate that when all normal input is entered, the system will notify the user of those employees that can attend and those that can not.
• Inputs:
  Start Time: 3:00 pm, Duration: 1.5 hrs, Date: March 20/96, Employees Invited: Bob - can attend, Joe - can not attend, Elvis - can not attend, Dave - can attend.
• Expected Outputs:
  A window with two list boxes should appear. In the first, labeled" Employees Available" should be Bob and Dave. In the second, labeled "Employees Unavailable" should be Joe and Elvis.

• Objective:
  These tests demonstrate that if a user attempts to schedule a meeting on a date/time that has past, the system will notify the user of his error.
• Inputs:
  All data as in Test 1, except:
  Test 2a) Start Date: March 19/95, Start Time: 2:00 pm.
  Test 2b) Start Date: February 17/96, Start Time: 2:00 pm.
  Test 2c) Start Date: March 17/96, Start Time: 12:00 pm.
• Expected Outputs:
  Outputs expected: In each case, the program should immediately inform the user of the error that occurred.

Test Supervisor: Michael Cullingham
Overall objective: These tests are designed to ensure that when called, this module returns optimal time for a meeting (storing it in the date/time fields), and informs the user of the best time. For this discussion, the day that the user is scheduling the meeting is assumed to be March 17, 1996 and the time is 1:00pm.

Test 1: Normal input

• Objective:
  This test will demonstrate that when all normal input is entered, the system will find the best possible time slot.
• Inputs:
  Test 1a) Day Range: March 18/96 - March 18/96, Time Range: 9:00 am - 1:00 pm, Duration: 1.5 hrs, Employees Invited: Bob - busy 9:00am - 10:00am, Joe - busy 9:00am - 9:30am, Elvis - busy 9:30am - 10:00am, - busy 10:30am - 11:00am, Dave - busy 12:30pm - 1:00pm.
  Test 1b) In addition to the times in Test 1a: Bob - busy 11:30am - 1:00pm
• Expected Outputs:
  Test 1a) All employees can make it. The best time here is 11:00am - 12:30pm
  Test 1b) 3/4 employees can make it. The best time here is 10:00am - 11:30am

• Objective:
  This test demonstrates that the system should notify the user that no employees can attend in this time period.
• Inputs:
  All data as in Test 1, except: Only 1/4 employees can attend at any given time in the range specified.
• Expected Outputs:
  In this test, the program should notify the user that only one or fewer employees can attend the meeting in the time range specified.

• Objective:
  This test demonstrate that if a user wants to find a time for a meeting on a date/time that has past, the system will notify the user of his error.
• Inputs:
  All data as in Test 1, except: Day Range: March 16, 1996 - March 16, 1996
• Expected Outputs:
  In this case, the program should immediately inform the user of the error that occurred.

• Objective:
  These tests demonstrate that if a user wants to find a time for a meeting from a later date to an earlier date, the system will notify the user of his error.
• Inputs:
  All data as in Test 1, except: Day Range: March 16, 1996 - March 14, 1996
• Expected Outputs:
  In this case, the program should immediately inform the user of the error that occurred.

Test Supervisor: Hiu Lee (Roger)
Overall objective: This module helps the user to set up his/her availability for daily routine schedule. It also allows the user to change his/her availability after the normal schedule is set up.

Test 1:

• Objective:
  Test the invalid input of date or time period.
• Success Criteria:
  The input date and time period must be past.
• Inputs:
  Choose the date period which is already past or Choose the time period which is already past.
• Expected Outputs:
  Warning message.
• Walkthrough:
  The module compares the input date with the current date, then it compares the input time with the current time if the input date is equal to the current date.

• Objective:
  Test the valid input of date and time period.
• Success Criteria:
  The input date and time period must not be past.
• Inputs:
  Choose the date period which is future or Choose the time period which is future.
• Expected Outputs:
  Confirmation message.
• Walkthrough:
  Peter is a new employee in the company. He needs to set up his own availability for the coming meetings. He uses the mouse pointer to select Monday till Friday, then he clicks the 9:00am till 5:00pm within the selected days of the week. The computer system will only schedule the meeting within this period of time if he is free for meeting.

• Objective:
  Test the change of availability after the initialization.
• Success Criteria:
  The input date and time period must not be past and must be previously set.
• Inputs:
  Choose the date period which is future or Choose the time period which is future.
• Expected Outputs:
  Confirmation message.
• Walkthrough:
  After Peter sets up his regular availability of time, he would like to change his availability to not available for this Wednesday afternoon because he got a physical exam. So, he uses the mouse pointer to input the date of this Wednesday (March 6, 96) and select the whole period of the afternoon. Then he checks the grid "Not Available" and he gets the confirmation message. After finished the setting, he chooses the week view to check the color change on the time slot according to what he has set for.

Test Supervisor: Hiu Lee (Roger)
Overall objective: This module allows the user to scroll through his/her messages and to click on them to get more in-depth details. It also allows the user to delete the message as it is expired.

Test 1:

• Objective:
  Notification of a new meeting requiring your attendance.
• Success Criteria:
  It must be someone else who creates a meeting and invites this user to attend. There must be no time conflict between the meeting and the user's availability.
• Inputs:
  None.
• Expected Outputs:
  Corresponding notification.
• Walkthrough:
  Peter logins to the Time Tracker system and finds out a new coming message that he is already invited to an executive meeting at 2:00pm tomorrow.

• Objective:
  Notification of the system attempting to schedule user into a meeting
• Success Criteria:
  It must be someone else who creates a meeting and invites this user to attend. On the other hand, there must be a time conflict between the meeting and the user's availability.
• Inputs:
  None.
• Expected Outputs:
  Corresponding notification.
• Walkthrough:
  Peter logins to the Time Tracker system and finds out a new coming message that he is invited to an executive meeting, but his time slot is not available. The message requests him to adjust his schedule and tries his best to attend the meeting because it is important.

• Objective:
  Notification that a meeting invitee, for a meeting user has scheduled, has declined the invitation.
• Success Criteria:
  There must be a time conflict between the meeting and the invitee's availability. So, the invitee may refuse the meeting because he/she will not be able to attend.
• Inputs:
  None.
• Expected Outputs:
  Corresponding notification and the name(s) of invitee who is not able to attend the meeting.
• Walkthrough:
  Peter logins to the Time Tracker system and finds out a new coming message that Mary is not able to attend his meeting because she is not able to rearrange her schedule.

• Objective:
  Notification of a canceled future meeting.
• Success Criteria:
  There must be someone who has set up the meeting and has invited the user to attend the meeting. Then he/she cancels the meeting; so the user receives the cancellation message.
• Inputs:
  None.
• Expected Outputs:
  Corresponding notification.
• Walkthrough:
  Peter logs in to the Time Tracker system and finds out a new coming message that the executive meeting is already canceled; so he will stay in his office tomorrow afternoon.

• Objective:
  Notification of a change in meeting plans/ideas that user is going to attend.
• Success Criteria:
  It must be someone else who creates a meeting and invites this user to attend. He/She changes some or all the meeting information such as the meeting place.
• Inputs:
  None.
• Expected Outputs:
  Corresponding notification with updated information.
• Walkthrough:
  Peter logins to the Time Tracker system and finds out a new coming message that the place for the executive meeting will be changed to Room 413.

• Objective:
  The user can click on a message and get the in-depth details.
• Success Criteria:
  There must be a message with the hidden details.
• Inputs:
  None.
• Expected Outputs:
  The details of the message will be shown.

• Objective:
  After the user reads a message, it will no longer be a new message upon re-entry.
• Success Criteria:
  There is at least one message which is already read by user.
• Inputs:
  None.
• Expected Outputs:
  No new/unread message.

• Objective:
  After the message is deleted, it will no longer exist in the system.
• Success Criteria:
  There is at least one message for the user and he/she wants to delete it.
• Inputs:
  None.
• Expected Outputs:
  The deleted message won't be shown after the deletion.

• Objective:
  The user is not allowed to delete a message which is tagged as new/unread.
• Success Criteria:
  There must be at least one new/unread message for the user.
• Inputs:
  None.
• Expected Outputs:
  Warning message.

Test Supervisor: Russ Magee
Overall objective: This test plan is designed to verify that the Aliases Module performs the tasks required of it, as outlined in the Overall Design Document.

Test 1: Creating a new group/alias.

• Objective:
  Entering a New Group.
• Inputs:
  New group name.
• Expected Outputs:
  New group is added to database.
• Walkthrough:
  Click on the white text entry box beside the label "Name of Group:". Delete any pre-existing text and type in the name of a new group. Click on the "Add" button at the bottom of the window to add the alias to the database. Verify that the alias has been added to the database by clicking on the drop-down arrow to the right of the "Name of Group:" text entry box, and search through the drop-down list to verify the new alias has been stored.

• Objective:
  Entering a Group with a Conflicting Name.
• Inputs:
  Group name that is already present in user's alias list.
• Expected Outputs:
  Error message stating that alias already exists; Program displays group with conflicting name in window.
• Walkthrough:
  Click on the white text entry box beside the label "Name of Group:". Delete any pre-existing text and type in the name of a group which is known to exist already. click on the "Add" button at the bottom of the window, and verify that an error message is displayed.

• Objective:
  Entering a Group With No Members.
• Inputs:
  A new or pre-existing group name; Null list of Employees in Group
• Expected Outputs:
  Error message stating that no employees are currently in group. Prompt user for group removal.
• Walkthrough:
  Click on the dropdown arrow beside the "Name of Group:" textbox. Locate a group and select it. Click on the "<<" button in the center of the window to remove all employees from the group. Click on the close button (NW corner of window). Verify that an alert box stating "Group is Null -- remove?" is displayed. Respond to the alert box with "Yes" and re-enter Alias Module to verify that group was removed. Repeat above procedure, this time responding "No" to alert box and re-enter Alias Module to verify group was preserved in its original state. Repeat above procedure, but click "Cancel" button instead of closing window and verify that group is NOT changed by re-entering Alias Module.

Test 4: Deleting a group/alias.

• Objective:
  Deleting a Group.
• Inputs:
  Group name to delete.
• Expected Outputs:
  Group is removed from database
• Walkthrough:
  Click on the drop-down arrow to the right of the "Name of Group:" text entry box, and search through the drop-down list to locate the desired group. Click on the group to be deleted. The drop-down list will disappear and the "Name of Group:" text entry box will display the group's name. The "Employees in Group" window (righthand text box) will display the list of employees belonging to that group. Click on the "Remove" button to remove the group. Verify that the group name is no longer present in the "Name of Group:" drop-down list box.

Test 5: Edit an existing group/alias.

• Objective:
  Editing a Group.
• Inputs:
  Group name to edit; Employee names to add/remove from group.
• Expected Outputs:
  Group is updated to reflect changes.
• Walkthrough:
  Click on the drop-down arrow to the right of the "Name of Group:" text entry box, and search through the drop-down list to locate the desired group. Click on the group to be edited. The drop-down list will disappear and the "Name of Group:" text entry box will display the group's name. The "Employees in Group" window (righthand text box) will display the list of employees belonging to that group. Locate an employee in the lefthand listbox entitled "Available Employees". Click on the employee name to highlight it. Click on the button labeled ">" to copy the employee name to the listbox entitled "Employees in Group". Verify the name appears in the "Employees in Group" listbox. Re-select the group from the "Name of Group:" dropdown listbox to force a re-fetch of the group from the database. Verify that changes are reflected in the group.

  Locate an employee in the lefthand listbox entitled "Available Employees". Click on an employee name that is ALREADY PRESENT in the current group. Click on the button labeled ">" to copy the employee name to the listbox entitled "Employees in Group". Verify that the name IS NOT copied into the "Employees in Group" listbox (ie., two copies of the same name are not present). Re-select the group from the "Name of Group:" dropdown listbox to force a re-fetch of the group from the database. Verify that changes are reflected in the group.

  Locate an employee in the righthand listbox entitled "Employees in Group". Click on an employee name. Click on the button labeled "<" to remove the employee from the current group. Verify that the name is removed from the "Employees in Group" listbox. Re-select the group from the "Name of Group:" dropdown listbox to force a re-fetch of the group from the database. Verify that changes are reflected in the group.

  Click on the ">>" button to add all employees to the current group. Verify that ALL employees are represented (only once) in the "Employees in Group" listbox. Re-select the group from the "Name of Group:" dropdown listbox to force a re-fetch of the group from the database. Verify that changes are reflected in the group.

  Click on the "<<" button to remove all employees present in the current group. Verify that the "Employees in Group" listbox becomes empty. Re-select the group from the "Name of Group:" dropdown listbox to force a re-fetch of the group from the database. Verify that changes are reflected in the group.

  Repeat all above tests, clicking on the "Cancel" button after each stage of the procedure. Re-enter the Alias Module and verify that the interrupted procedure is NOT reflected in the database.

Stage 2: Integration Tests

Test Supervisor: Chris Mohr
Overall objective: These tests will show that when a button is pressed from the main menu, the appropriate module will come up.

Test 1:

• Objective:
  Will show proper calling of Scheduling function.
• Inputs:
  Button click on "Scheduler".
• Expected Outputs:
  Will bring up dialog box "Scheduler".

• Objective:
  Will show proper calling of Messages function.
• Inputs:
  Button click on "Messages".
• Expected Outputs:
  

• Objective:
  Will show proper calling of Availability function.
• Inputs:
  Button click on "Availability".
• Expected Outputs:
  Will bring up dialog box "Availability".

• Objective:
  Will show proper calling of Employees function.
• Inputs:
  Button click on "Employees".
• Expected Outputs:
  Will bring up dialog box "Employees".

• Objective:
  Will show proper movement of the calendar to previous month.
• Inputs:
  Button click on Calendar "<" button.
• Expected Outputs:
  Will bring up previous months calendar.

• Objective:
  Will show proper movement of the calendar to next month.
• Inputs:
  Button click on Calendar's ">" button.
• Expected Outputs:
  Will bring up next months calendar.

• Objective:
  Will show proper calling of View Meeting function.
• Inputs:
  Button click meeting block in calendar viewing area.
• Expected Outputs:
  Will bring up dialog box "View Meeting".

• Objective:
  Will show proper termination of program.
• Inputs:
  Button click on "Exit".
• Expected Outputs:
  Will terminate program.

Test Supervisor: Russ Magee
Overall objective: This test plan is designed to verify that the Event Handler Module performs all tasks required of it, as outlined in the Overall Design Document.

Test 1:

• Objective:
  Click on all buttons mentioned above to call each module in the system.
• Inputs:
  Mouse clicks.
• Expected Outputs:
  Varies; all main modules in the system will be accessed from this module.
• Walkthrough:
  Click on the month buttons labeled "<" and ">" above the calendar to change the scheduler's month. Verify that the month displayed changes, and in the proper direction. Verify that movement beyond 4 months in the future is not allowed. (button labeled ">" should become disabled) Click on each day within the month. Verify that the week containing the day selected is displayed in the daytimer window. Verify that meetings for the week selected are displayed in the daytimer view. Verify that clicking on a blank day in the month (no number in box) does nothing (or beeps to tell user of invalid selection). Click on the "Scheduler" button. Verify that the Scheduler Module (3.3) is invoked. Click on the "Messages" button. Verify that the Messages Module (3.5) is invoked. Click on the "Availability" button. Verify that the Availability Module (3.4) is invoked. Click on the "Employees" button. Verify that that Employees Module (4) is invoked. Click on hour/day squares in daytimer view containing meeting titles. Verify that Scheduler Screen is invoked, showing detailed information for the proper meeting. Click on blank hour/day squares in daytimer. Verify that a blank Scheduler Screen is invoked, allowing entry of a new appointment. Click on all sliders/scroll arrows to verify proper screen updates.

Test Supervisor: Chris Mohr
Overall objective: These tests will show that the calling of modules from the scheduler event handler are all in working order.

Test 1:

• Objective:
  Make sure that you can select a meeting.
• Inputs:
  Click on a meeting.
• Expected Outputs:
  Get a meeting sub-dialog box.

• Objective:
  Make sure that you can cancel a meeting.
• Inputs:
  Click on a "cancel meeting".
• Expected Outputs:
  Get a cancel meeting sub-dialog box.

• Objective:
  Make sure that you can schedule a meeting.
• Inputs:
  Click on a "schedule" a meeting.
• Expected Outputs:
  Get a schedule meeting sub-dialog box.

• Objective:
  Make sure that you can manually schedule a meeting.
• Inputs:
  Click on a "Automatic" scheduling.
• Expected Outputs:
  Get a reply on the automatic scheduling.

Test Supervisor: Russ Magee
Overall objective: This test plan is designed to verify that the Event Handler Module performs all tasks required of it, as outlined in the Overall Design Document.

Test 1:

• Objective:
  Click on all parts of calendar mentioned above to call manipulate the time period viewable from the system.
• Inputs:
  Mouse clicks.
• Expected Outputs:
  Daytimer window and calendar graphic will be updated to reflect user input.
• Walkthrough:
  Click on the month buttons labeled "<" and ">" above the calendar to change the scheduler's month. Verify that the month displayed changes, and in the proper direction. Verify that movement beyond 4 months in the future is not allowed. (button labeled ">" should become disabled) Click on each day within the month. Verify that the week containing the day selected is displayed in the daytimer window. Verify that meetings for the week selected are displayed in the daytimer view. Verify that clicking on a blank day in the month (no number in box) does nothing (or beeps to tell user of invalid selection).

Stage 3: Functional Tests

• Availability
  Verify that employees may set their own availability for meetings. This should include regular work hours, with exceptions on a daily basis. (Eg., weekdays 9 to 5, plus 10-2 on Sundays)
• Meeting Creation
  Verify that users are able to create meetings on a daily, weekly, or monthly basis as well as 'one-time-only' meetings.

  Verify that users may create meetings in two ways:
  1. Automatic: Request the system to find the first available time slot that all employees can attend. System notifies creator if there are conflicts, and prompts for acceptability of these conflicts.

  2.Manual: Give a specific time for a meeting. Creator is notified of any conflicts, and may schedule meeting in spite of these conflicts.

  Verify that users are invited to meetings by their FULL names, to avoid any possible confusion.

  Verify that people invited to meetings are notified with a message specifying the time, location and date of the meeting.

  Verify that a newly created meeting appears on the daytimer window and its priority is indicated by the color code specified by the user.

  Verify that only people free to attend a meeting are scheduled for one.

  Verify that the creator of a meeting is notified of people who cannot attend at the desired time.

  Verify that users invited to a meeting see it on their daytimer when they next enter the application.

  Verify that the system notifies users of a new invitation while they are in the application.

  Verify that users are able to decline a meeting.

  Verify that the creator of a meeting is notified of the decline.

• Meeting Deletion
  Verify that users are able to delete meetings they have created.

  Verify that ONLY the meeting's creator (or the Supervisor) may cancel a meeting.

  Verify that people invited to the deleted meeting are notified of the cancellation.

  Verify that the deletion of a meeting is reflected on the daytimers of all users subsequently entering the system.

• Schedule Reporting
  Verify that a user's schedule may be printed (daily, weekly, monthly).

  Verify that under NO circumstances is a user's schedule modified without his/her full knowledge.

• Overall System Performance
  Verify that system has no long, unexplained delays.

  Verify that any unavoidable delays are accompanied by a visual notice stating the reason.

Stage 4: Performance Evaluation

Test Supervisor: Danny Yerex
Overall Objective: This overall plan is designed to see if an employee can enter the system, make an appointment, and leave, in a reasonable amount of time (30 sec/2 min), for both user scheduled and computer scheduled appointments.

Start Time

Test 1: Login Module Test procedure

Test 2: Schedule Meeting Test procedure (manual)

Test 3: Confirm existence of meeting on weekly grid.

Stop Time

Start Time

Test 1: Login Module Test procedure

Test 2: Schedule Meeting Test procedure (automatic)

Test 3: Confirm existence of meeting on weekly grid.

Stop Time

Test Supervisor: Danny Yerex
Overall Objective: To see how easy it is/how much time it takes to enter the system and review a given week.

Start Time

Test 1: Login Module Test procedure

Test 2: Click appropriate week to view (Calendar module Test Procedure)

Test 3: View week, click a specific meeting

Stop Time

Stage 5: Acceptance Tests

However, should terms of contract and negotiations be overlooked, we may draw up a NEW contract to include the NEW terms negotiated as enhancements.

To allow our customers a test drive of the system, we decided the actual end users a TWO WEEK trial period of the system at NO COST. During which, they may contact our Customer Support Service on our 24-hr Support Service line at toll-free (1-800-Axiom-En) to report or inquire about the system.

The trial package will include the Time Tracker System's User Manual & System Specifications. The trial period will commence in the period of March 19th to March 31st 1996. Any loss of data during this trial period is solely the responsibility of the users.