Software Test Plan
for
Ticket Tracking System
Version 2.0
Prepared by:
Team 8
MSC
Samuel Harrington
Colton Manville
Michael Slezak
Prepared for:
Dr. Manuel L. Penaloza
CSC 470 Instructor
South Dakota School of Mines and Technology
Spring 2011
April 1, 2011
Table of Contents
1.0 Introduction ..................................................................................................... 3
1.1 Purpose of Document ................................................................................... 3
1.2 Definitions, Acronyms, and Abbreviations .................................................... 3
2.0 System Test Cases ............................................................................................ 4
2.1 User .............................................................................................................. 4
2.2 Staff ............................................................................................................ 10
2.3 Manager ..................................................................................................... 16
2.4 Admin ......................................................................................................... 19
3.0 Testing Results ............................................................................................... 22
4.0 Traceability Matrix ......................................................................................... 23
5.0 Conclusion ..................................................................................................... 23
3
1.0 Introduction
1.1 Purpose of Document
The purpose of this document is to detail how the product will be tested for conformance
to the requirements. It will list a series of unambiguous tests to determine whether the
product is ready for use. In addition, this document will later be expanded to include a
record of the product readiness. The tests will be run under the latest two versions of
Internet Explorer, Google Chrome, and Firefox. The server will be running the latest
versions of Apache, MySQL, and PHP.
1.2 Definitions, Acronyms, and Abbreviations
Throughout this paper, a number of acronyms, definitions, and abbreviations will be used:

MySQL: A program used for managing databases and executing database queries.

PHP: Server-side scripting language for developing web pages on a web server.

JavaScript: Client-side scripting language for enriched interaction with the user.

jQuery: JavaScript library to help program a rich user interface for the website.

Apache: web server software used for hosting a website on the internet.

HTML: Hyper-Text Markup Language, defines webpages for browsers to render

SDSM&T: South Dakota School of Mines and Technology

MCS: Math and Computer Science

SVN: Subversion, code management software

GUI: Graphical User Interface
4
2.0 System Test Cases
2.1 User
2.1.1 TU1
Purpose:
Test if users can log in.
Test Input Data:
Create a user with username “Login_test_user” and password
“1234567890qWeRtY[]\!@#$%^&*()-=”. Attempt to log in as
“Login_test_user” & “1234567890qWeRtY[]\!@#$%^&*()-=”,
“login_test_user” & “1234567890qWeRtY[]\!@#$%^&*()-=”,
“not_a_user” & “1234567890qWeRtY[]\!@#$%^&*()-=”,
“Login_test_user” & “1234567890qwerty[]\!@#$%^&*()-=”, and
“Login_test_user” & “jhgjhgfkjhgkjhgjhg”.
Expected outcome: Only the correct (first) username and password allow you to log
in. All others present the error: “Invalid Username/Password”.
2.1.2 TU2
Purpose:
Test if users can see the incident reports they have submitted.
Test Input Data:
The tester will login as the user ‘User’.
The tester will submit a ticket titled ‘Viewing Test’.
The tester will navigate to the ticket viewing page and select the
‘Submitted’ tab.
Expected outcome: The ticket ‘Viewing Test’ will appear in the ticket list in the
‘Submitted’ tab.
5
2.1.3 TU3
Purpose:
Test if users can submit incident reports.
Test Input Data:
The tester will login as the user ‘User’.
The tester will navigate to the ticket submission page and submit
a ticket with the title ‘Submission Test’, and the description ‘This
is a test.’
The tester will login as the user ‘IT Staff’.
The tester will navigate to the ticket viewing page and select the
‘New’ tab.
Expected outcome: The ticket ‘Submission Test’ will appear in the ticket list in the
‘New’ tab.
2.1.4 TU4
Purpose:
Test if users can change their password.
Test Input Data:
Create a new user with password “password1” and log in. On the
preferences page, input the following combinations into the old,
new, and confirm fields and press submit:
“password1”, “password2”, “password2”
“password1”, “password2”, “asdf”
“asdf”, “password2”, “password2”
“asdf”, “password2”, “qwerty”
6
Expected outcome: Only in the first case does the password get changed successfully
to “password2”. The other cases output an error stating either
the old password is wrong, or the new passwords do not match.
2.1.5 TU5
Purpose:
Test if users can change preferences.
Test Input Data:
Create a new user and log in. Enter each of the following on the
Preferences page, pressing submit after each:
First name: “Bob”
Last name: “Felderstein-goldberg”
Phone: “555-555-5555”
Email: “someone@someplace.jp”
Last name: “Jones”, First name: “Desiree”
Expected outcome: The preferences are changed to match the entered data, and
persist until changed.
2.1.6 TU6
Purpose:
Test if users can search through tickets.
Test Input Data:
The tester will clear the MySQL ticket table.
The tester will use a MySQL query to insert two tickets into the
ticket table.
The first ticket will contain the following information:
7
Title: Ticket Alpha
Description: Win
Status: In Progress
Priority: Normal
Owner: Admin
Submitter: IT Staff
Date Submitted: 10/20/2010
Date Modified: 10/20/2010
The second ticket will contain the following information:
Title: Ticket Beta
Description: Lose
Status: Approved
Priority: High
Owner: Manager
Submitter: User
Date Submitted: 3/12/2011
Date Modified: 3/12/2011
The tester will perform the following searches:
1) Keywords: Alpha, Win
2) Status: In Progress
3) Priority: Normal
4) Owner: Admin
8
5) Submitter: IT Staff
6) Modified: 1/10/2010 – 1/10/2011
7) Modified: 1/10/2010 – 1/10/2012
8) Submitter: IT Staff, User
9) Owner: Admin, Manager
10) Priority: Normal, High
11) Status: In Progress, Approved
12) Keywords: Ticket
13) Keywords: Pickle
14) Status: New
15) Priority: Low
16) Owner: IT Staff
17) Submitter: Admin
18) Modified: 1/10/2011 – 2/10/2011
19) Keywords: Ticket, Alpha, Win
Status: Approved
Priority: High
Owner: Manager
Submitter: User
Modified: 3/12/2011 – 3/12/2011
9
Expected outcome: In Searches 1 – 6, and 19 only the ticket ‘Ticket Alpha’ will be
displayed.
In Searches 7 – 12 both ‘Ticket Alpha’ and ‘Ticket Beta’ will be
displayed.
In Searches 13 – 18 the phrase ‘No Search Results’ will be
displayed.
2.1.7 TU7
Purpose:
Test if users can comment on tickets they have submitted.
Test Input Data:
Login as “User”. Create a new incident. Open the incident.
Attempt to comment on the incident. Open an incident the user
did not create. Attempt to comment on the incident.
Expected outcome: If the user submitted the ticket, the comment is appended to the
comment description – otherwise, an error is displayed.
2.1.8 TU8
Purpose:
Test if passwords are stored securely.
Test Input Data:
Create a user “Hash_test” and set the password to “password”.
Open the database in a viewer such as phpMyAdmin, and view
the contents of the User table.
Expected outcome: The password column of the row for “Hash_test” should appear
similar to “$1$t.5.yN3.$eFrG/9HffNxHalRUpaFvI1”.
10
2.2 Staff
2.2.1 TS1
Purpose:
Test if staff can comment on tickets that they are assigned to.
Test Input Data:
The tester will create a ticket titled ‘Commenting Test’.
The tester will login as the user ‘Manager’.
The tester will assign the ticket to the user ‘IT Staff’.
The tester will login as the user ‘IT Staff’.
The tester will view the ticket ‘Commenting Test’.
The tester will submit a comment with the text ‘Hello World’.
Expected outcome: The ticket titled ‘Commenting Test’ will contain a comment with
the text ‘Hello World’.
2.2.2 TS2
Purpose:
Test if staff can comment on tickets that are not assigned to
them.
Test Input Data:
The tester will create a ticket titled ‘Comment Test Ticket’.
The tester will login as the user ‘Manager’.
The tester will assign the ticket to the user ‘Admin’.
The tester will login as the user ‘IT Staff’ and search for the ticket
‘Comment Test Ticket’.
The tester will view the ticket titled ‘Comment Test Ticket’.
11
Expected outcome: The comment submission box will not appear on the ticket
viewing page.
2.2.3 TS3
Purpose:
Test if staff can modify priority and category of assigned ticket.
Test Input Data:
The tester will create a ticket titled ‘New Ticket’, with the priority
‘Low’, and the category ‘Software’.
The tester will then login as the user ‘Manager’.
The tester will assign the ticket ‘New Ticket’ to the user ‘IT Staff’.
The tester will then login as the user ‘IT Staff’.
The tester will navigate to the ticket modification page for the
ticket ‘New Ticket’.
The tester will change the priority to ‘High’ and the category to
‘Hardware’.
Expected outcome: The ticket ‘New Ticket’ will change from ‘Low’ priority to ‘High’
priority, and the category will change from ‘Software’ to
‘Hardware’.
2.2.4 TS4
Purpose:
Test if staff can view list of unverified tickets, assigned tickets,
and completed tickets.
12
Test Input Data:
The tester will create three tickets titled ‘Unverified Ticket’,
‘Assigned Ticket’, and ‘Completed Ticket’.
The tester will login as the user ‘Manager’ and assign the tickets
‘Assigned Ticket’ and ‘Completed Ticket’ to the user ‘IT Staff’.
The tester will then login as the user ‘IT Staff.
The tester will then navigate to the ticket viewing page and
select the ‘Assigned’ tab.
The tester will select the ticket ‘Completed Ticket’ and submit it
for completion.
The tester will then login as the user ‘Manager’.
The tester will then mark the ticket ‘Completed Ticket’ as
‘Completed’.
The tester will then login as the user ‘IT Staff’.
The tester will then navigate to the ticket viewing page and
select the ‘New’, ‘Assigned’, and ‘Completed’ tabs.
Expected outcome: The tester will see the ticket ‘Unverified Ticket’ in the ‘New’ tab.
The tester will see the ticket ‘Assigned Ticket’ in the ‘Assigned’
tab.
The tester will see the ticket ‘Completed Ticket’ in the completed
tab.
13
2.2.5 TS5
Purpose:
Test that staff can only see unverified tickets and not list of
tickets assigned to other staff.
Test Input Data:
The tester will create a ticket titled ‘Invisible Ticket’ and a ticket
titled ‘Visible Ticket’.
The tester will then login as the user ‘Manager’.
The tester will assign the ticket titled ‘Invisible Ticket’ to the user
‘Admin’.
The tester will then assign the ticket ‘Visible Ticket’ to the user ‘IT
Staff’.
The tester will then login as the user ‘IT Staff’.
The tester will then perform a search for all tickets.
Expected outcome: The tester will be able to see the ticket ‘Visible Ticket’, but will
not be able to see the ticket ‘Invisible Ticket’.
2.2.6 TS6
Purpose:
Test that staff can verify unverified tickets.
Test Input Data:
The tester will submit a ticket titled ‘Test Ticket’.
The tester will log in as the user ‘IT Staff’.
The tester will navigate to the ticket viewing page and select the
‘new’ tab.
The tester will select the ticket ‘Test Ticket’.
14
The tester will then click the ‘Verify’ button in the ticket
modification window.
Expected outcome: The ticket’s status will change from ‘New’ to ‘Verified’.
2.2.7 TS7
Purpose:
Test that staff can request approval to continue with a ticket or
to close the ticket by setting the ticket status.
Test Input Data:
The tester will login as the user ‘IT Staff’.
The tester will create a ticket titled ‘Test Approval Ticket’.
The tester will then use the account ‘Manager’ to assign the
ticket to the user ‘IT Staff’.
The tester will then log in as the user ‘IT Staff’.
The tester will navigate to the ticket modification page, and
submit the ticket for approval with the phrase ‘Need New
Computer’.
The tester will then log into the account ‘Manager’ and approve
the request.
The tester will then log into the account ‘IT Staff’, navigate to the
ticket modification page, and submit the ticket for completion.
Expected outcome: The ticket’s status will change from ‘In Progress’ to ‘Approval
Pending’ and will contain the comment ‘Approval Pending: Need
New Computer’.
15
The ticket status will then change from ‘Approved’ to ‘Pending
Completion’.
2.2.8 TS8
Purpose:
Test that staff can perform all actions of a user including: ticket
submission, changing user preferences, and viewing personal
tickets.
Test Input Data:
Perform tests TU2-TU6 logged in as the user ‘IT Staff’ instead of
the user ‘User’.
Expected outcome: Expected outcomes for TU2 – TU6.
16
2.3 Manager
2.3.1 TM1
Purpose:
To test FRM1, Manager can modify any field of a ticket
Input Test Data:
The tester will submit a ticket with the title ‘Test Ticket’, the
description ‘This is a test’, and the type ‘Software’.
The tester will change the title to ‘Modified Ticket’.
The tester will change the priority to ‘High’.
The tester will change the ticket type to ‘Hardware’.
The tester will assign the ticket to the user ‘User’
Expected Output:
The ticket will have the title ‘Modified Ticket’, the priority ‘High’,
the type ‘Hardware’, and will be assigned to the user ‘User’
2.3.2 TM2
Purpose:
To test FRM2, Manager can perform all IT Staff actions
Input Test Data:
Perform tests TS1, TS4, and TS6 – TS8 logged in as the user
‘Manager’ instead of ‘IT Staff’.
Expected Output:
Expected Output for TS1, TS4, and TS6 – TS8.
2.3.3 TM3
Purpose:
To test FRM3, Manager can view tickets pending approval
Input Test Data:
The tester will submit a ticket titled ‘Pending Approval Ticket’
and will set the status to ‘Pending Approval’.
17
The tester will then navigate to the ticket viewing page and
select the ‘Pending Approval’ tab.
Expected Output:
The tester will see the ticket ‘Pending Approval Ticket’ in the
pending approval list.
2.3.4 TM4
Purpose:
To test FRM3, Manager can view unassigned tickets
Input Test Data:
The tester will create a ticket with the name ‘Unassigned Ticket’.
The tester will then navigate to the ticket viewing page and
select the ‘New’ tab.
Expected Output:
The tester will be able to see the ticket ‘Unassigned Ticket’ in the
new ticket list.
2.3.5 TM5
Purpose:
To test FRM3, Manager can view verified tickets
Input Test Data:
The tester will create a ticket with the name ‘Verified Ticket’ and
set the status to ‘Verified’.
The tester will then view the ‘verified’ tab on the ticket viewing
page.
Expected Output:
The tester will see the ticket ‘Verified Ticket’ in the list of verified
tickets.
18
2.3.6 TM6
Purpose:
To test FRM4, Manager can comment on any ticket
Input Test Data:
The tester will select a ticket named ‘Manager Test Ticket’ and
submit the comment ‘Comment Test’.
Expected Output:
The ticket ‘Manager Test Ticket’ will contain a comment
‘Comment Test’.
19
2.4 Admin
2.4.1 TA1
Purpose:
To test FRA1, Admin can remove users
Input Test Data:
Go to the “Users” page. Create a new user named “Delete_test”.
Select the checkbox next to the user in the list, and press “Delete
User”. Log out and attempt to log in as “Delete_test”.
Expected Output:
The user shows up with a strikethrough through their name and
cannot log in, with the error message “Invalid Username or
Password”.
2.4.2 TA2
Purpose:
To test FRA1, Admin can add users
Input Test Data:
Go to the “Users” page. Press “Add new user”, and enter in the
username “Create_test”, role “Manager”, and a valid email
address.
Expected Output:
An email should be sent to the email address with instructions to
set the password and log in.
2.4.3 TA3
Purpose:
To test FRA2, Admin can change user permissions
Input Test Data:
Go to the “Users” page. Create a user “Role_test” as a “User”.
Select “IT Staff” from the drop-down next the user’s name. Press
20
“Update permissions”. Select “Manager”, “Admin”, and “User” in
turn, pressing “Update permissions” after each.
Expected Output:
The drop-down should change to show the role you selected for
the user, after pressing “Update permissions”.
2.4.4 TA4
Purpose:
To test FRA2, Admin cannot change own permissions
Input Test Data:
Create two new admin users named “Admin_test1” and
“Admin_test2”. Make sure you are logged in as “Admin_test1”.
Go to the “Users” page.
Expected Output:
There should not be a drop-down list after the user
“Admin_test1”, but there should be one after “Admin_test2”.
2.4.5 TA5
Purpose:
To test FRA3, Admin can perform all IT Manager actions
Input Test Data:
Perform TM1 – TM6 logged in as the user ‘Admin’ instead of the
user ‘Manager’.
Expected Output:
Expected Output of TM1 – TM6.
21
2.4.6 TA6
Purpose:
To test FRA4, Admin can reset passwords
Input Test Data:
Go to the “Users” page. Create a new user named “Reset_test”
with any role and a valid email address. Select the checkbox next
to that user, and press “Reset password”.
Expected Output:
An email should be sent to the email address with instructions on
how to set a new password.
22
3.0 Testing Results
TU1
TU2
TU3
TU4
TU5
TU6
TU7
TU8
TS1
TS2
TS3
TS4
TS5
TS6
TS7
TS8
TM1
TM2
TM3
TM4
TM5
TM6
TA1
TA2
TA3
TA4
TA5
TA6
IE 8
SLEH
CSM
CSM
SLEH
SLEH
MS
MS
SLEH
CSM
CSM
CSM
CSM
CSM
CSM
CSM
CSM
CSM
CSM
CSM
CSM
CSM
CSM
SLEH
SLEH
SLEH
SLEH
CSM
SLEH
Chrome 10
SLEH
CSM
CSM
SLEH
SLEH
MS
MS
SLEH
CSM
CSM
CSM
CSM
CSM
CSM
CSM
CSM
CSM
CSM
CSM
CSM
CSM
CSM
SLEH
SLEH
SLEH
SLEH
CSM
SLEH
FF 4.0
SLEH
CSM
CSM
SLEH
SLEH
MS
MS
SLEH
CSM
CSM
CSM
CSM
CSM
CSM
CSM
CSM
CSM
CSM
CSM
CSM
CSM
CSM
SLEH
SLEH
SLEH
SLEH
CSM
SLEH
23
4.0 Traceability Matrix
FRG1
FRU1
FRU2
FRU3
FRU4
FRU5
FRU6
FRU7
FRU8
FRS1
FRS2
FRS3
FRS4
FRS5
FRS6
FRS7
FRS8
FRM1
FRM2
FRM3
FRM4
FRA1
FRA2
FRA3
FRA4
Tests
TS8
TU1
TU2
TU3
TU4
TU5
TU6
TU7
TU7
TS1
TS3
TS4
TS8
TS4
TS6
TU7
TS7
TM1
TM2
TM3
TM6
TA1
TA3
TA5
TA6
TM2 TA5
TS2
TS5
TS1
TM6
TM4 TM5
TA2
TA4
5.0 Conclusion
The tests above make sure that all functional requirements are met on all supported
browsers. Every functional requirement has at least one test to verify the requirement is
met. The tests were run on the latest versions of Firefox, Chrome, and Internet Explorer.
The tests were all verified to run correctly.