Clinic Appointment Scheduler System

ConcordiaUniversity

Department of Computer Science

Software Test Plan

STP

CASS

Clinic Appointment Scheduler System

Table of Content

1.Introduction

1.1Purpose

1.2Scope

1.3Intended Audience

1.4Document Terminology and Acronyms

1.5References

1.6Document Structure

2.Evaluation Mission and Test Motivation

2.1Background

2.2Evaluation Mission

2.3Test Motivators

3.Target Test Items

4.Test Cases

4.1Login

4.2Logout

4.3Create Patient Profile (Patient)

4.4Create Department (Administrator)

4.5Create Type Appointment (Administrator)

4.6Create Doctor Profile (Administrator)

4.7Book an Appointment(Patient)

4.8Doctor consults appointment

4.9Edit Doctor Profile (Administrator)

4.10Edit Patient Profile

4.11Cancel Doctor’s Appointment (Administrator)

4.12Cancel Doctor’s Appointment (Doctor)

4.13Cancel Patient’s Appointment (Patient)

1.Introduction

This document is to serve as Master Test Approach for the Clinic Appointment Scheduler System (C.A.S.S.).

1.1Purpose

The purpose of the Master Test Plan is to gather all of the information necessary to plan and control the test effort. It describes the approach to testing the software, and is the top-level plan generated and used by team members to direct the test effort.

In This Test Plan for the CASS supports the following objectives:

Identifies the items that should be targeted by the tests.
Identifies the motivation for and ideas behind the test areas to be covered.
Outlines the testing approach that will be used.
Identifies the required resources and provides an estimate of the test efforts.
Lists the deliverable elements of the test project.

Preparation for this test consists of three major stages:-

The Test Approach sets the scope of system testing, the overall strategy to be adopted, the activities to be completed, the general resources required and the methods and processes to be used to test the release. It also details the activities, dependencies and effort required to conduct the System Test.
Test Planning details the activities, dependencies and effort required to conduct the System Test.
Test Conditions/Cases documents the tests to be applied, the data to be processed, the automated testing coverage and the expected results.

1.2Scope

The C.A.S.S. is a web-based application system. The project is a team effort. As such, it will be necessary to unit test, integration test, and system test the project according to the functional requirements of the system as outlined in the SRS. The test plan presents data and database integrity, function, integration, unit user interface, performance profiling, and also installation testing.

1.3Intended Audience

This document describes the test plan for the C.A.S.S. and was done to partially fulfill the requirements for computer science course COMP 5541, ConcordiaUniversity, Montreal, Quebec. It is intended primarily for academic purposes although it could be of interest to commercial worldwide.

The test team will include the same team members used to develop the code. Traditionally, this represents a conflict of interest. Because this is a university class with limited resources, it will be necessary to circumvent some traditional testing practices.

1.4Document Terminology and Acronyms

C.A.S.S. / Clinic Appointment Scheduler System
OS / Operating System
DB / Database
DBMS / Database Management System
HTML / Hypertext Markup Language
HTTP / Hypertext Transfer Protocol
PHP / Hypertext Preprocessor or Personal Home Page
MySQL / It is an open source relational database management system

1.5References

[1] Pankaj Kamthan, (current September 22, 2005).

[2] Wikipedia, (current September 22, 2005).

1.6Document Structure

The rest of the document presents the following major parts:

Evaluation mission : contains a brief background on this project and its objectives
Test motivation: contains a brief background on the motivations for testing
Target test items: includes what tests will and will not be performed
Outline of planned tests
Test approach: contains the actual tests that were performed and how the tests were carried out.

2.Evaluation Mission and Test Motivation

2.1Background

The aim in phase III is to implement the C.A.S.S. web application after we set the software requirement specifications and the design of this application in phase I and phase II respectively. The majority of this application is written in PHP and in HTML.

The following test plan is aimed to ensure the created application meets the requirement specifications and design criteria. It also ensures the production of reliable software and reduces future maintenance costs.

2.2Evaluation Mission

The goal of this test plan is to ensure that the HRS meets the specifications and design criteria of the two previous phases. In order to achieve this goal, the test plan will detail the methodology used for integrating and testing the application. This procedure enables the production of higher quality software.

2.3Test Motivators

The first goal of testing is bug prevention. Prevented bugs reduce costs, cause no code to be corrected, and cannot wreck a schedule. Bug prevention is a state of mind. Developers need to make software testable. Good programmers test early and often to keep their bugs to a minimum.

The second goal of testing is to discover symptoms caused by bugs by using many small detailed tests. To make these tests repeatable, test cases must be designed, tested, and documented. Only then, can useful regression testing take place.

Finally, bugs must be clearly diagnosed so they can be easily corrected.

In order to achieve these goals we should consider the following motivators

Quality risks: The application needs to be tested with those previously outlined methods (section 1.2) for any quality failure setbacks.
Technical risks: The application needs to be tested with those previously outlined methods (section 1.2) for any technical errors in the system.
Functional requirements (Use cases): The application needs to be tested to ensure that each use case has been correctly implemented.
Non functional requirements (Design elements): Reliability, usability, understandability, security, maintainability and portability all have to be evaluated in order to show the degree of accuracy of the final software with respect to what has been outlined in the system requirement software document (phase I).
Suspected failures/faults: The application needs to be tested with those previously outlined methods (section 1.2) for any malfunctions in the system.

3.Target Test Items

Software, hardware, and supporting product elements are identifying targets items for testing .

3.1 Graphical user interface testing

Graphical user interface (GUI) testing is performing tests to verify that the user interface can execute the required functions for the end usersas described in the design document.

The following Graphical items will be considered in testing:

Login
Logout
Create Patient Profile (Patient)
Create Department (Administrator)
Create Type Appointment (Administrator)
Create Doctor Profile (administrator)
Book an appointment (Patient)
Doctor Consults appointments
Edit Doctor Profile (administrator)
Edit Patient Profile
Cancel Doctor's Appointment (Administrator)
Cancel Doctor's Appointment (Doctor)
Cancel Patient's Appointment (Patient)

4.Test Cases

4.1Login

Rational: There are three kinds of uses of C.A.S.S: patient, doctor, and administrator. To use the C.A.S.S system, all uses need to be identified and authorized. Users enter their username and password to login the system. After their username and password are verified, a corresponding menu page (either administrator menu page, doctor menu page, or patient menu page) will be on the left frame of the page based on user’s role. (either patient, doctor, or admin). Meanwhile, a session will store username and other key information to trace user’s state.

Case# / Input Data / Expected Results
Case 1:
Login page / Enter

correct user Name

correct password and

press on login Button

Displays the welcome information to the user
Based on the user’s role (admin, doctor, or patient), the corresponding menu page (admin menu, doctor menu, and patient menu) will be displayed on the left frame of the page.

Case 2:
Login page / Enter

correct User Name

incorrect Password and

press on login Button

Displays error message :”Please check your user name and password and try again.”
None of admin menu page, doctor menu page, or patient menu page are available.

Case 3:
Login page / Enter

incorrect User Name

correct Password and

Press on login Button

Displays error message :”Please check your user name and password and try again.
None of admin menu page, doctor menu page, or patient menu page are available.

Case 4:
Login page /

Not enter any username or password
Press login button.

Display error message “ please input your username and password to retry.”

Case 5.
Login page /

Click “Signup” button to register as a new patient

Link to the “register as new patient ” page.

Case 6
Login fail page /

Click “try again” hyperlinks

Links to the login page for users to retry.

4.2Logout

Rational: after users logout, they are not be able to use system unless they login again. Therefore, after user logout, the login page will be re-directed, and the related menu pages(admin menu page, or doctor menu page, or patient menu page) are not available. Also, after logout, user should not be able to return to the previous web page by clicking “backward ” button on web browsers.

Case# / Input Data / Expected Results
Case 1:
Logout menu /

User click the logout menu

Redirect to the login page
The menu pages only has “login” and “register “ two menu items

Case 2:
Backward menu /

After logout, user tries to return previous web page by clicking “backward” menu button on web browsers.

Previous web pages should not be accessed, because the session is destroyed in logout.

4.3Create Patient Profile (Patient)

Rationale: On the home page, a new patient can choose ‘New Registration’ option from the menu. The patient will be able to see a form where he/she will be required to fill in all the relevant information in the given fields. The patient can fill in the fields and press the ‘Submit’ button in the form to submit the information to the database.

Case # / Input Data / Expected Results
CASE 1 /

Fill in all the fields in the registration form as required
Press Submit button

Display a message confirming that new patient record created successfully

CASE 2 /

Leave all the fields empty
Press Submit button

Display an error message that user needs to fill in the required information
Ask the user to enter information in the form again

CASE 3 /

Fill in the fields according to an existing patient
Press Submit button

Display a message that the record already exists

CASE 4 /

Fill in the fields as required
Leave mandatory field/s empty
Press Submit button

Display an error message that required field/s is not filled in
Ask the user to enter information in the form again

CASE 5 /

Fill in a field and exceed the limit of number of characters/digits allowed
Press Submit button

Display an error message to show which field is not entered correctly
Ask the user to enter information in form again

CASE 6 /

Fill in a field with characters/digits not allowed for that field
Press Submit button

Display an error message to show which field is not entered correctly
Ask the user to enter information in form again

4.4Create Department (Administrator)

Rationale: After logging in, the Administrator can choose ‘CreateNewDepartment’ option from the menu. The Administrator will be able to see a form where he/she will be required to fill in all the relevant information in the given fields. The Administrator can fill in the fields and press the ‘Submit’ button in the form to submit the information to the database.

Case # / Input Data / Expected Results
CASE 1 /

Fill in the fields in New Department form as required
Press Submit button

Display a message confirming that a new Department is created successfully

CASE 2 /

Fill in the fields according to an existing Department
Press Submit button

Display a message that the record already exists

CASE 3 /

Leave all the fields empty
Press Submit button

Display an error message that user needs to fill in the required information
Ask the user to enter information in the form again

CASE 4 /

Fill in the fields in form as required
Leave a mandatory field empty
Press Submit button

Display an error message that required field/s is not filled in
Ask the user to enter information in form again

CASE 5 /

Change a field and exceed limit of the number of characters/digits allowed
Press Submit button

Display an error message to show which field is not entered correctly
Ask the user to enter information in form again

CASE 6 /

Change a field with characters/digits not allowed for that field
Press Submit button

Display an error message to show which field is not entered correctly
Ask the user to enter information in form again

4.5Create Type Appointment (Administrator)

Rationale: After logging in, the Administrator can choose ‘CreateNewAppointmentType’ option from the menu. The Administrator will be able to see a form where he/she will be required to fill in all the relevant information in the given fields. The Administrator can fill in the fields and press the ‘Submit’ button in the form to submit the information to the database.

Case # / Input Data / Expected Results
CASE 1 /

Fill in the fields in New Appointment type form as required
Press Submit button

Display a message confirming that a new Appointment type is created successfully

CASE 2 /

Fill in the fields according to an existing Appointment Type
Press Submit button

Display a message that the record already exists

CASE 3 /

Leave all the fields empty
Press Submit button

Display an error message that user needs to fill in the required information
Ask the user to enter information in the form again

CASE 4 /

Fill in the fields in the form as required
Leave a mandatory field empty
Press Submit button

Display an error message that required field/s is not filled in
Ask the user to enter information in form again

CASE 5 /

Fill in a field and exceed limit of the number of characters/digits allowed
Press Submit button

Display an error message to show which field is not entered correctly
Ask the user to enter information in form again

CASE 6 /

Fill in a field with characters/digits not allowed for that field
Press Submit button

Display an error message to show which field is not entered correctly
Ask the user to enter information in form again

CASE 7 /

Fill the field Duration as 0
Press Submit button

Display an error message to show that this is not an accepted value.

4.6Create Doctor Profile (Administrator)

Rationale: A doctor should have a personal profile activated before being able to have agenda. The administrator has to create this profile, which would create a doctor login name and a password. The administrator must login first, then clicks on the “create doctor account” from the menu, then fill a special form for doctor’s info and once completed a new doctor account is active and can receive appointments.

Case # / Input Data / Expected Results
CASE 1 /

Fill all fields with correct values
Click on submit button

A new web page is displayed containing a message displayed informing the administrator that a doctor profile was created successfully.

CASE 2 /

Provide a Doctor Login ID that already exists in the system
Fill all other fields in the form correctly.
Click on submit button

An error message displayed, informing the administrator of a duplicate login-ID provided.

“Doctor account <login-ID> already exist please modify it! “
CASE 3 /

The password field is filled with a value different from that given in the “Confirm Password” field.
All other fields are filled correctly.
Click on submit button.

A pop up error message is displayed informing the administrator that the two passwords do not confirm.

“The 2 passwords entered does not confirm”
CASE 4 /

An email address entered but missing the dot (.) part, or the @ sign.
All other fields are entered correctly.
Click on Submit button

A pop up error message is displayed informing the administrator that the email address is incomplete.

“The email address entered in not complete”
CASE 5 /

The phone number field is filled with letters only or a combination of letters and numbers.
All other fields are filled correctly.
Submit button is clicked.

A pop up error message is displayed informing the administrator that the phone number is should not be characters

“The phone value should be a number”
CASE 6 /

All form fields are left empty
Submit button is clicked.

A pop up error message is displayed listing all the missed fields.

Case 7 /

All/Some field are filled with some data
The “Reset” Button is clicked

All Fields will become empty.

4.7Book an Appointment(Patient)

Rationale: After logging into CASS, the patient has the option to schedule an appointment. In order to successfully schedule an appointment, the patient must follow a five step process: select appointment type, select month and year, select day, select time, and confirm. Once this five step process had been successfully completed, the patient will receive a confirmation.

Case # / Input Data / Expected Results
CASE 1 /

Arrive at Schedule Appointment interface

Backend: Personal information (patient key, user ID, health card number, first name, last name, date of birth, address, telephone number, email address) is stored in session
Interface: Step 1 (select appointment type) is displayed; displays appointment types from the database

CASE 2 /

Select appointment type using radio buttons (default is other)
Click Submit button

Backend: Appointment type information (type key, department key, type name, estimated duration) is stored in session
Interface: Step 2 (select month and year) is displayed

CASE 3 /

Select month from drop down menu (default is January)
Select year from drop down menu (default is 2006)
Click Submit button

Backend: Month and year are stored in session
Interface: Step 3 (select day) is displayed; displays calendar of month and year

CASE 4 /

Click on a day from the calendar

Backend: Day is stored in session
Interface: Step 4 (select time) is displayed; displays time slots for day according to estimated duration of appointment type; displays available time slots in green and un-available time slots in red according to database

CASE 5 /

Click on a green time slot (red time slots cannot be clicked)

Backend: Start time and end time are stored in session
Interface: Step 5 (confirm) is displayed; displays appointment type, date, time with patient health card number, name, date of birth, address, telephone number, email address

CASE 6 /

Click Confirm button

Backend: Appointment (appointment key, doctor key, patient key, type key, date, start time, end time, memo, status) is inserted into the database
Interface: Confirmation is displayed; displays appointment type, date, time with patient health card number, name, date of birth, address, telephone number, email address

4.8Doctor consults appointment