Concordia University: S T P STP

Concordia University
Department of Computer Science
SOFTWARE TEST PLAN

STP
CASS
CLINIC APPOINTMENT SCHEDULER SYSTEM
Table of Content
1. Introduction..................................................................................................................3
1.1 Purpose................................................................................................................3
1.2 Scope........................................................................................................................3
1.3 Intended Audience...............................................................................................3
1.4 Document Terminology and Acronyms...............................................................4
1.5 References............................................................................................................4
1.6 Document Structure.............................................................................................4
2. Evaluation Mission and Test Motivation.....................................................................4
2.1 Background..............................................................................................................4
2.2 Evaluation Mission..............................................................................................4
2.3 Test Motivators....................................................................................................5
3. Target Test Items..........................................................................................................5
4. Test Cases....................................................................................................................6
4.1 Login....................................................................................................................6
4.2 Logout..................................................................................................................7
4.3 Create Patient Profile (Patient)............................................................................7
4.4 Create Department (Administrator).....................................................................8
4.5 Create Type Appointment (Administrator)..........................................................9
4.6 Create Doctor Profile (Administrator)...............................................................10
4.7 Book an Appointment(Patient)..........................................................................11
4.8 Doctor consults appointment.............................................................................13
4.9 Edit Doctor Profile (Administrator)...................................................................15
4.10 Edit Patient Profile.............................................................................................16
4.11 Cancel Doctor’s Appointment (Administrator).................................................17
4.12 Cancel Doctor’s Appointment (Doctor).............................................................18
4.13 Cancel Patient’s Appointment (Patient).............................................................18
1. Introduction
This document is to serve as Master Test Approach for the Clinic Appointment
Scheduler System (C.A.S.S.).
1.1 Purpose
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:-
2. 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.
3. Test Planning details the activities, dependencies and effort required to conduct
the System Test.
4. Test Conditions/Cases documents the tests to be applied, the data to be
processed, the automated testing coverage and the expected results.
1.2 Scope
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.3 Intended 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, Concordia University, 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.4 Document 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.5 References
[1] Pankaj Kamthan, http://cmvl.cs.concordia.ca/courses/comp-5541/fall-2005/ (current
September 22, 2005).
[2] Wikipedia, http://www.wikipedia.org/ (current September 22, 2005).
1.6 Document 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.1 Background
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.2 Evaluation 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.3 Test 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 users as described in the design document.
The following Graphical items will be considered in testing:
1. Login
2. Logout
3. Create Patient Profile (Patient)
4. Create Department (Administrator)
5. Create Type Appointment (Administrator)
6. Create Doctor Profile (administrator)
7. Book an appointment (Patient)
8. Doctor Consults appointments
9. Edit Doctor Profile (administrator)
10. Edit Patient Profile
11. Cancel Doctor's Appointment (Administrator)
12. Cancel Doctor's Appointment (Doctor)
13. Cancel Patient's Appointment (Patient)
4. Test Cases
4.1 Login
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: Enter  Displays the welcome information to
Login page  correct user Name the user
 correct password and  Based on the user’s role (admin,

doctor, or patient), the corresponding
 press on login Button menu page (admin menu, doctor
menu, and patient menu) will be
displayed on the left frame of the
page.
Case 2: Enter  Displays error message :”Please
Login page  correct User Name check your user name and password
and try again.”
 incorrect Password and  None of admin menu page, doctor
menu page, or patient menu page are
 press on login Button available.
Case 3: Enter  Displays error message :”Please

 incorrect User Name check your user name and password
Login page and try again.
 correct Password and  None of admin menu page, doctor
menu page, or patient menu page are
 Press on login Button available.
Case 4:  Not enter any username or  Display error message “ please input
Login page password your username and password to
retry.”
 Press login button.
Case 5.  Click “Signup” button to  Link to the “register as new patient ”
Login page register as a new patient page.
Case 6  Click “try again” hyperlinks  Links to the login page for users to
Login fail retry.
page
4.2 Logout
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:  User click the logout menu  Redirect to the login page
Logout menu
 The menu pages only has “login” and
“register “ two menu items
Case 2:  After logout, user tries to  Previous web pages should not be
Backward return previous web page by accessed, because the session is
menu clicking “backward” menu destroyed in logout.
button on web browsers.
4.3 Create 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  Display a message confirming that
registration form as required new patient record created
 Press Submit button successfully
CASE 2  Leave all the fields empty  Display an error message that user
 Press Submit button 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  Display a message that the record
existing patient already exists
 Press Submit button
CASE 4  Fill in the fields as required  Display an error message that required
 Leave mandatory field/s empty field/s is not filled in
 Press Submit button  Ask the user to enter information in
the form again
CASE 5  Fill in a field and exceed the limit  Display an error message to show
of number of characters/digits which field is not entered correctly
allowed
form again
CASE 6  Fill in a field with characters/digits  Display an error message to show
not allowed for that field which field is not entered correctly

form again
4.4 Create 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 1  Fill in the fields in New  Display a message confirming that a
Department form as required new Department is created
 Press Submit button successfully
existing Department already exists
information
the form again
CASE 4  Fill in the fields in form as  Display an error message that required
required field/s is not filled in
 Leave a mandatory field empty  Ask the user to enter information in
 Press Submit button form again
CASE 5  Change a field and exceed limit of  Display an error message to show
the number of characters/digits which field is not entered correctly
allowed
form again
CASE 6  Change a field with  Display an error message to show
characters/digits not allowed for which field is not entered correctly
that field
4.5 Create 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 1  Fill in the fields in New  Display a message confirming that a
Appointment type form as new Appointment type is created
required successfully
existing Appointment Type already exists
information
the form again
CASE 4  Fill in the fields in the form as  Display an error message that required
required field/s is not filled in
CASE 5  Fill in a field and exceed limit of  Display an error message to show
allowed
form again
CASE 6  Fill in a field with characters/digits  Display an error message to show
not allowed for that field which field is not entered correctly

form again
CASE 7  Fill the field Duration as 0  Display an error message to show that
this is not an accepted value.
4.6 Create 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 1  Fill all fields with correct  A new web page is displayed
values containing a message displayed
 Click on submit button informing the administrator that a
doctor profile was created
successfully.
CASE 2  Provide a Doctor Login ID that  An error message displayed,

already exists in the system informing the administrator of a
 Fill all other fields in the form duplicate login-ID provided.
correctly. “Doctor account <login-ID> already exist
 Click on submit button please modify it! “
CASE 3  The password field is filled  A pop up error message is
with a value different from that displayed informing the
given in the “Confirm administrator that the two
Password” field. passwords do not confirm.
 All other fields are filled
“The 2 passwords entered does not
correctly. confirm”
 Click on submit button.
CASE 4  An email address entered but  A pop up error message is displayed

missing the dot (.) part, or the @ informing the administrator that the
sign. email address is incomplete.
 All other fields are entered
correctly. “The email address entered in not
complete”
 Click on Submit button
CASE 5  The phone number field is filled  A pop up error message is displayed
with letters only or a combination informing the administrator that the
of letters and numbers. phone number is should not be
 All other fields are filled correctly. characters
 Submit button is clicked. “The phone value should be a number”

CASE 6  All form fields are left empty  A pop up error message is displayed
 Submit button is clicked. listing all the missed fields.
Case 7  All/Some field are filled with  All Fields will become empty.
some data
 The “Reset” Button is clicked
4.7 Book 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 1  Arrive at Schedule  Backend: Personal
Appointment interface 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  Backend: Appointment
using radio buttons type information (type
(default is other) key, department key,
 Click Submit button type name, estimated
duration) is stored in
session
month and year) is
displayed
CASE 3  Select month from drop  Backend: Month and
down menu (default is year are stored in
January) session
 Select year from drop  Interface: Step 3 (select
down menu (default is day) is displayed;
2006) displays calendar of
 Click Submit button month and year
CASE 4  Click on a day from the  Backend: Day is stored
calendar in session
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  Backend: Start time and
slot (red time slots end time are stored in
cannot be clicked) 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.8 Doctor consults appointment

Rational: The doctor should be able to consult his appointments. There is three ways he
can use to search for the records: search by patient name, search by appointment date, or
search by both of them. If there is any record, it will be displayed in a table; otherwise,
the system will show a message to tell the user no record is found.
CASE 1 Enter  Displays the records in a table
 Choose a patient name
 Check the check box before
patient name
 There is some records exist

CASE 2 Enter  Displays error message :”Please
 Choose a patient name choose the item you want to consult!”
 Not check the check box
before patient name
CASE 3 Enter  Display a message: “No record is

 Choose a patient name found.”
 check the check box before
patient name
 There is no record exist

CASE 4 Enter  Displays the records in a table
 Choose a date
 Check the check box before
the date

 Choose a date choose the item you want to consult!”
 Not check the check box
before patient name

 Choose a date found.”
 check the check box before
patient name
 There is no record exist

CASE 7 Enter  Display the records
 Choose a date
 Check the check boxes of
them

 Choose a date choose the item you want to consult!”
 Not check them

 Choose a date found.”
 Check them
 There is no records exist
4.9 Edit Doctor Profile (Administrator)

Rationale: The doctor’s information may need changes; the administrator can modify the
profile after logging in. He should click the “Edit Doctor Profile” button from the
administrator menu. Then choose a specified doctor’s name from a drop down list, and
then the profile form will appear with all doctor information displayed in its relevant
fields. Note that the page where the administrator chooses a doctor name contains only a
drop-down list with all doctors’ names found in the database, and once a name is chosen,
the page is redirected instantly. Therefore, the user interaction is limited and errors are
trapped.
Case 1 Try to change the “Login ID”  Since this field is read only
field nothing will happen.
Case 2 Nothing changed in the form  Backend: Fields related to the
fields. doctor chose are re-saved in
Submit button is clicked. the Doctor and User tables in
the database.
 Interface: A new web page
viewed with a confirmation
message.
“Doctor Profile was updated
successfully!”
Case 3 The password field is filled  A pop up error message is

with a value different from displayed informing the
that given in the “Confirm administrator that the two
Password” field. passwords do not confirm.
All other fields are filled “The 2 passwords entered does not
correctly. confirm”
Submit button is clicked.
Case 4 All/Some Fields in the form  A pop up error message is
are left without displayed listing all the missed
modification. fields.
Submit button is clicked.
Case 5  An email address modified  A pop up error message is displayed

missing the dot (.) part, the @ informing the administrator that the
sign or both email address is incomplete.
 All other fields are modified
correctly, or left without “The email address entered in not
modification. complete”
 Click on Submit button

Case 6  The phone number field is  A pop up error message is displayed
modified to contain letters informing the administrator that the
only or a combination of phone number is should not be
letters and numbers. characters
 All other fields are modified
correctly or left unchanged “The phone value should be a number”
 Submit button is clicked.

Case 7  All/Some fields are modified.  All Fields will have their initial value
again.
 The “Reset” Button is clicked
4.10 Edit Patient Profile

Rationale: After logging in, the patient can choose ‘Profile’ option from the menu. The
patient will be able to see a form filled with all the relevant information in the form fields
that is retrieved from the database as was provided by her/him before. The patient can
change any/all fields and press the ‘Update’ button in the form to submit the changes to
the database.

CASE 1  Change the fields in Update form  Display a message confirming that
as required Database is updated successfully
 Press Update button
CASE 2  Change the fields in Update form  Display an error message that required
as required field is not filled in
 Press Update button form again
CASE 3  Change a field and exceed limit of  Display an error message to show
allowed
 Press Update button  Ask the user to enter information in
form again
CASE 3  Change a field with  Display an error message to show
characters/digits not allowed for which field is not entered correctly
that field
 Press Update button form again
4.11 Cancel Doctor’s Appointment (Administrator)

Rationale: Upon choosing the criteria for cancellation an appointment by the
Administrator , the system will retrieve all patient first and second names into a list
besides to that the system will display a calendar so the administrator can retrieve
appointment(s) by date Then, the user indicates his final choice by choosing from
available options. The criteria must be specified correctly, and valid data must be
obtained..
CASE 1  Check to select Patient’s first and  Display all the information related to
second name the selected patient’s appointment(s)
 Check an appointment to Cancel  Cancel the selected appointment by
 Press Submit button changing the appointment status into 1
CASE 2  Check to select Patient’s  Display all the information related to
Appointment’s date the selected patient’s appointment(s)
 Check an appointment to Cancel
 Press Submit button  Cancel the selected appointment by
changing the appointment status into 1
CASE 3  Press Submit button without  Display an alert message informing
selecting any appointment(s) to the user to select an appointment to
cancel cancel
4.12 Cancel Doctor’s Appointment (Doctor)

Rationale: The system will retrieve all patient’s first and second names into a list related
to the doctor Id i.e. all the patients of login doctor besides to that the system will display
a calendar so the doctor can retrieve appointment(s) by date Then, the user indicates his final
choice by choosing from available options. The criteria must be specified correctly, and valid data must be
obtained..
CASE 1  Check to select Patient’s first and  Display all the information related to
second name the selected patient’s appointment(s)
 Check an appointment to Cancel  Cancel the selected appointment by
 Press Submit button changing the appointment status into 1
CASE 2  Check to select Patient’s  Display all the information related to
Appointment’s date the selected patient’s appointment(s)
 Check an appointment to Cancel
 Press Submit button  Cancel the selected appointment by
cancel cancel
4.13 Cancel Patient’s Appointment (Patient)

Rationale: The system will retrieve all appointment(s) information related to the User Id
Then, the user indicates his final choice by choosing from available options. The criteria must be specified
correctly, and valid data must be obtained..
CASE 1  Check an appointment to Cancel  Display all the information related to
 Press Submit button the selected patient’s appointment(s)
 Cancel the selected appointment by
CASE 2  Check an appointment to Cancel  Display all the information related to
 Press Submit button the selected patient’s appointment(s)
 Cancel the selected appointment by

cancel cancel

Concordia University: S T P STP

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Concordia University: S T P STP

Uploaded by

Copyright:

Available Formats

Concordia University

Department of Computer Science

SOFTWARE TEST PLAN

Preparation for this test consists of three major stages:-

1.3 Intended Audience

1.4 Document Terminology and Acronyms

[2] Wikipedia, http://www.wikipedia.org/ (current September 22, 2005).

1.6 Document Structure

2. Evaluation Mission and Test Motivation

2.3 Test Motivators

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

3.1 Graphical user interface testing

The following Graphical items will be considered in testing:

Case# Input Data Expected Results

 correct password and  Based on the user’s role (admin,

Case 3: Enter  Displays error message :”Please

Case# Input Data Expected Results

4.3 Create Patient Profile (Patient)

Case # Input Data Expected Results

 Press Submit button  Ask the user to enter information in

4.4 Create Department (Administrator)

Case # Input Data Expected Results

4.5 Create Type Appointment (Administrator)

Case # Input Data Expected Results

 Press Submit button  Ask the user to enter information in

4.6 Create Doctor Profile (Administrator)

Case # Input Data Expected Results

CASE 2  Provide a Doctor Login ID that  An error message displayed,

CASE 4  An email address entered but  A pop up error message is displayed

 Submit button is clicked. “The phone value should be a number”

 The “Reset” Button is clicked

4.7 Book an Appointment(Patient)

Case # Input Data Expected Results

4.8 Doctor consults appointment

 There is some records exist

CASE 3 Enter  Display a message: “No record is

 There is no record exist

 There is some records exist

CASE 6 Enter  Display a message: “No record is

 There is no record exist

CASE 8 Enter  Displays error message :”Please

CASE 9 Enter  Display a message: “No record is

4.9 Edit Doctor Profile (Administrator)

Case 3 The password field is filled  A pop up error message is

Case 5  An email address modified  A pop up error message is displayed

 Click on Submit button

 Submit button is clicked.

4.10 Edit Patient Profile

Case # Input Data Expected Results

4.11 Cancel Doctor’s Appointment (Administrator)

4.12 Cancel Doctor’s Appointment (Doctor)

4.13 Cancel Patient’s Appointment (Patient)

 Cancel the selected appointment by

You might also like