Online Health Monitoring System

Test Plan

COP4331, Fall, 2014

Modification history:

Version	Date	Who	Comment
v0.0	8/15/00	G. H. Walton	Template
v1.0	9/9/14	C. Chaffin	First Draft
v2.0	9/9/2014	J. Luke	Added Section 4 and major revisions to other sections
v2.1	9/15/14	C. N. McCue	Minor Revisions

Team Name: Project 14

Team Members:

· Jon Carelli - email - web page

· Chris McCue - email - web page

· Chris Chaffin - email - web page

· Ethan Pitts - email - web page

· David Gundler - email - web page

· James Luke - email - web page

---

Contents of this Document

1. Introduction:

Overall Objective for Software Test Activity

Reference Documents

2. Description of Test Environment
3. Overall Stopping Criteria
4. Description of Individual Test Cases

---

SECTION 1: Introduction

· Overall Objective for Software Test Activity:

The objective of the test plan is to identify activities that will help produce an application with quality performance, usability, and functionality, by way of creating test cases and identifying bugs.

The software test will ensure that our PHP functions are working as documented, our server connectivity is sufficient, our video chat service can support our target load, and that our web pages are displayed properly.

Reference Documents:

• Concept of Operations
• Software Requirement Specification
• Project Management Plan

---

SECTION 2: Description of Test Environment

We will run our tests on a Virtual Private Server, running a light LAMP stack. This is the most cost efficient and powerful combination for running our application on the web. The application requires at least 512MB of RAM, 1 GHz single core processor, and the ability to connect to the Internet. This test environment would be the same environment that the software would run in after deployment.

Developers will do initial testing, as development progresses users will be asked to test software and provide feedback. If a user finds a bug it will be recorded (create issue ticket with note that this was found by a user and not a team member) and sent to the development team for a solution. At this point, Chris Chaffin will be the tester. This, however, is subject to change.

---

SECTION 3: Stopping Criteria

The criteria for a stop will be rated according to the importance of the error.

Bugs will be classified on a scale of 1-4, one being the most critical and four representing a problem with a workaround.

· For a bug to be rated 1 there must be a critical error in the application. For example: on launching the application the program crashes before fully loading. Bugs with a rating of 1 will be the most important and of the highest priority.

· A rating of 2 is representative of a bug that needs to be addressed quickly and sometimes crashes the application.

· A rating of 3 is considered to be medium priority, but still needs to be addressed. This type of bug does not crash the system, but prevents some sort of work from being done.

· A rating of 4 is of the lowest priority. These types of bugs are changes that we would like to implement, but are not necessary for the end goal.

If errors are found during testing, the above criteria will be utilized to determine the seriousness of the bug. Bugs of 1 and 2 ratings will require immediate attention. If bugs of ratings 3 or 4 are encountered, we will continue the series of tests as far as possible, recording all bugs that appear. The results of the unit tests will indicate clearly which functions are problematic.

If no errors are found, it will be assumed that the software is working as intended, as long as the unit tests are thorough enough.

If the application is working as documented, meets specifications, and does not contain errors reachable by end users, it will be declared "good enough to deliver".

---

SECTION 4: Description of Individual Test Cases

· Test Objective: Create a user from the public web form and activate it

• Test Description 1: We will test adding a user to the database by a web form, using the following data:
• Email: any email reachable by the tester
• Username: test_user
• Password: UCF!Test

Then, open the activation email and click on the activation URL

• Test Conditions: We will run this test whenever the user signup form changes, and also if any database settings were changed.
• Expected Results: You will be brought to a page that asks you to look for a confirmation email. An email with an activation URL will be sent to the tester's email address. The user will be added to the database.

· Test Objective 2: Create and activate a doctor user from the public web form and activate it

• Test Description: We will test adding a doctor user to the database by a web form, using the following data:
• Email: any email reachable by the tester
• Username: test_doctor
• Password: UCF!Test

Then, open the activation email and click on the activation URL

• Test Conditions: We will run this test whenever the user signup form changes, and also if any database settings were changed.
• Expected Results: You will be brought to a page that asks you to look for a confirmation email. An email with an activation URL will be sent to the tester's email address. The user will be added to the database.

· Test Objective 3: User(patient) logs in

• Test Description: We will test logging in as a user, using the following credentials:
• Username: test_user
• Password: UCF!Test
• Test Conditions: We will run this test whenever the user login form changes, and also if any database settings were changed.
• Expected Results: You will be brought to the patient-specific dashboard page

· Test Objective 4: User(patient) requests a video chat

• Test Description: First complete test #3. Navigate to the chat request form. Request a chat from test_doctor for the next available time slot.
• Test Conditions: We will run this test whenever the video chat request form changes.
• Expected Results: test_doctor will be notified that the time slot has been filled. The timeslot table in the database will be updated.

· Test Objective 5: Doctor logs in

• Test Description: We will test logging in as a doctor, using the following credentials:
• Username: test_doctor
• Password: UCF!Test
• Test Conditions: We will run this test whenever the user login form changes, and also if any database settings were changed.
• Expected Results: You will be brought to the doctor-specific dashboard page

· Test Objective 6: Test video chat session

• Test Description: Log into the test_user and test_doctor accounts on separate computers. At the time scheduled in test #4, navigate to the video chat page on both machines.
• Test Conditions: We will run this test whenever the video chat page changes.
• Expected Results: The two users will be connected in a video chat session at the time scheduled in Objective 4.

· Test Objective 7: Assigning medicine

• Test Description: Log into the test_doctor account. Navigate to the schedule reminder page and select the test_user account. Schedule test_user to take TEST_MEDICINE once daily.
• Test Conditions: We will run this test whenever the schedule page changes.
• Expected Results: The reminder will be added to the database, and the test_user account will get a notification to take TEST_MEDICINE.

· Test Objective 8: Viewing reminders

• Test Description: Log into the test_user. Navigate to the reminder calendar.
• Test Conditions: We will run this test whenever the reminder calendar changes.
• Expected Results: A calendar should display all the reminders for test_user.

· Test Objective 9: Manage account

• Test Description: After logging into test user, navigate to the manage account page. Enter the following information to update the account.
• Name: John Doe
• Phone Number: 555-555-5555
• Email: any email reachable by the tester
• Video Chat credentials: a valid username and password to log in to the video chat service
• Test Conditions: We will run this test whenever the user account system changes.
• Expected Results: The results of the search should include the test_doctor account.

· Test Objective 10: Sending a message to the patient

• Test Description: Log in as test_doctor. Navigate to the messaging page and select test_user from the drop down list. Enter "Test Message" into the text field and hit the "Send Message" button.
• Test Conditions: We will run this test whenever the messaging system changes.
• Expected Results: test_user will see a popup on their page, displaying the test message.

· Test Objective 11: Logging out of a session

• Test Description: After logging into test user, log out of the account. Attempt to access the reminder calendar page. You should get a page that requests a log in.
• Test Conditions: We will run this test whenever the user account system changes.
• Expected Results: You should not be able to access any information about the test_user account after logging out.

---

Template created by G. Walton (GWalton@mail.ucf.edu) on March 28, 1999 and last modified on August 15, 2000.

This page last modified by Chris McCue (christopher.mccue@knights.ucf.edu) on 09/25/14