Professional Documents
Culture Documents
Testing Plan Test Case 1197505820674480 5 PDF
Testing Plan Test Case 1197505820674480 5 PDF
12/7/2007
Group 6
Version 1.0
Status Baseline
Le Vu Hoang
Huynh Da Thuc
Testing Plan Document
Table of Contents
1. Introduction .................................................................................................................................................7
5. Approach ................................................................................................................................................... 13
2
Testing Plan Document
5.2.8 Load Testing .............................................................................................................................. 19
5.2.9 Stress Testing ............................................................................................................................ 19
5.2.10 Volume Testing ......................................................................................................................... 20
6. Suspension criteria and resumption requirements .................................................................................. 21
7. Environmental Needs................................................................................................................................ 22
8. Schedule .................................................................................................................................................... 23
1. Unit testing................................................................................................................................................ 27
2.2 Fail to login the system when providing invalid username .............................................................. 28
2.3 Fail to login the system when providing valid username and invalid password .............................. 28
2.4 Fail to login the system when providing empty username ............................................................... 29
2.5 Fail to login the system when providing valid username and empty password............................... 29
2.7 User logs in the system using an account is being used by another user......................................... 30
2.8 User logs in the system using an account is being locked ................................................................ 30
2.10 User choose the wrong security question or type the wrong answer.............................................. 31
3
Testing Plan Document
2.11 User input the empty answer for the security question................................................................... 32
3.2 Fail to add a department with name that already exists in the system ........................................... 33
3.3 Fail to add a department when one or some or all fields are empty ............................................... 33
3.4 Fail to add a department when inputting special character(s) to one or some or all fields ............ 34
3.6 Fail to update a department with name that already exists in the system ...................................... 35
3.7 Fail to update a department when one or some or all fields are empty .......................................... 36
3.8 Fail to update a department when inputting special character(s) to one or some or all fields ....... 37
4.2 Fail to add a department when one or some or all fields are empty ............................................... 39
4.3 Fail to add a lecturer when inputting special character(s) to one or some or all fields ................... 40
4.6 Fail to update a lecturer when one or some or all fields are empty ................................................ 43
4.7 Fail to update a lecturer information when inputting special character(s) to one or some or all
fields 43
4
Testing Plan Document
5.1 Add a student with valid information successfully ........................................................................... 46
5.2 Fail to add a student when one or some or all fields are empty ...................................................... 46
5.3 Fail to add a student when inputting special character(s) to one or some or all fields ................... 47
5.5 Fail to search student by student ID or/and by student name when providing invalid student ID
or/and student name .................................................................................................................................... 48
5.6 Fail to search student by student ID or/and by student name when providing empty student ID
or/and student name .................................................................................................................................... 49
5.10 Fail to update a student when one or some or all fields are empty ................................................. 52
5.11 Fail to update a student information when inputting special character(s) to one or some or all
fields 52
6.4 Cancel during the Update list of course offering operation ............................................................. 57
6.6 Update list of course offering while there’s no list of course offering for specific faculty............... 58
5
Testing Plan Document
7.2 Fail to view tuition fee by student ID or/and by student name when providing invalid student ID
or/and student name .................................................................................................................................... 59
7.3 Fail to view tuition fee by student ID or/and by student name when providing empty student ID
or/and student name .................................................................................................................................... 60
7.5 View tuition fee by academic year, semester, and course ............................................................... 61
C- Appendix ................................................................................................................................................... 66
6
Testing Plan Document
A- Test Plan
1. Introduction
1.1 Purpose
This document describes the plan for testing the Online University Registration System [OURS]. This Test
Plan document supports the following objectives:
Identify ours project information and its components that should be tested.
Identify the required resources, provide an estimate of the test efforts, and detail testing schedule.
1.2 Scope
This Test Plan applies to unit test, integration test and system test that will be conducted on the Online
University Registration System [OURS]. It is assumed that unit testing already provided thorough black box
testing through extensive coverage of source code and testing of all module interfaces.
This Test Plan applies to test all requirements of the [OURS] as defined in the Vision and Scope Document,
Use-case specification, and software requirement specification document.
1.3 References
Vision and Scope document
7
Testing Plan Document
The detail of these use cases is described in SRS document. Therefore, we will not do it again in this
document.
However, according to recommendations from Ms Sang, we will add two more use cases. They are “Manage
User Account” and “Manage Course Catalog”.
Manage user account use case is used by a new actor of the system that is administrator. This use case
allows user to create, update, delete, and search for user account.
Manage course catalog is used by Academic Affair Staff. This use case allows user to add, delete, update,
and search for course in the course catalog.
Our team use Change Management technique introduced in the book “Applied Project Management” to
deal with these change. And the detail of these two use case specification and their test cases we will
provide in the final document which will be submit in review 4. In this document, we only introduce the
changes on requirement that our team has been made.
8
Testing Plan Document
9
Testing Plan Document
10
Testing Plan Document
11
Testing Plan Document
3. Features to be tested
We will perform testing on use case specification, functional requirement, and non-functional requirement
of all use cases and functions. They include
Login
Logout
Recovery password
Add a department
Update a department
Delete a department
Viewing information
Add a student
Update a student
Delete a student
Add a lecturer
Update a lecturer
Delete a lecturer
Viewing information
12
Testing Plan Document
(This is new use case. As we mentioned in previous part, we will write the detail and submit it in the review
4)
(This is new use case. As we mentioned in previous part, we will write the detail and submit it in the review
4)
The test cases will be separated in later part. Therefore we do not put the list of test cases here.
5. Approach
5.1 Kind of test
The tests below base on the use case specifications, functional requirements, and non-functional
requirements which have been identified as the targets for testing
Besides, we also show the kinds of test which our team intend to perform.
14
Testing Plan Document
5.2 Test Strategy
The Test Strategy presents the recommended approach to the testing of the software applications. The
previous section on Test Requirements described what kinds of test will be tested. This part describes how
they will be performed.
The main considerations for the test strategy are the techniques to be used and the criterion for testing to
be completed.
However, before starting the system test (both functional and non-functional requirements testing), we
must perform unit test for each unit of the system (fields, methods, classes, and components) and make
sure that all unit must pass the check list of unit test.
Verify the input data format specified in each form, classes, and interaction with database
String format
Date format
Special character
Empty field
Null
Test write
Doing this kind of checking help us to decrease the number of simple test cases
In order to complete this kind of test, we will use JUnit and EJB3Unit as tools for implement and execute the
unit test.
15
Testing Plan Document
5.2.3 Smoke test
Because the number of use cases and the number of test cases are really large, we cannot demo all of them.
Therefore we will define a smoke test for demonstration.
Our smoke test includes test cases of 3 main use cases of the system:
For the detail of each test case, please reference to the part of test case in later part.
All the tools that are used for test automation please reference to the part of tools in later part.
Test Objective Ensure Database access methods and processes function properly and
without data corruption.
Technique Invoke each database access method and process, seeding each with valid
and invalid data (or requests for data).
Inspect the database to ensure the data has been populated as intended, all
database events occurred properly, or review the returned data to ensure
that the correct data was retrieved (for the correct reasons)
Completion Criteria All database access methods and processes function as designed and without
any data corruption.
Special Considerations Testing may require a DBMS development environment or drivers to enter or
modify data directly in the databases.
16
Testing Plan Document
used to increase the visibility of any non-acceptable events.
Test Objective Ensure proper application navigation, data entry, processing, and
retrieval.
Technique Execute each use case, use case flow, or function, using valid and
invalid data, to verify the following:
Special Considerations Access to the OURS Server and the existing Course Catalog System is
required.
Additionally, Performance tests can be used to profile and tune a system's performance as a
function of conditions such as workload or hardware configurations.
17
Testing Plan Document
NOTE: Transactions below refer to "logical business transactions". These transactions are defined as specific
functions that an end user of the system is expected to perform using the application, such as add or modify
a given contract.
Test Objective Validate System Response time for designated transactions or business
functions under a the following two conditions:
Technique Use Test Scripts developed for Business Model Testing (System Testing).
Modify data files (to increase the number of transactions) or modify scripts
to increase the number of iterations each transaction occurs.
Scripts should be run on one machine (best case to benchmark single user,
single transaction) and be repeated with multiple clients (virtual or actual,
see special considerations below).
Completion Criteria Single Transaction / single user: Successful completion of the test scripts
without any failures and within the expected / required time allocation (per
transaction)
Use multiple physical clients, each running test scripts to place a load on
the system.
The databases used for Performance testing should be either actual size, or
18
Testing Plan Document
scaled equally.
NOTE: Transactions below refer to "logical business transactions". These transactions are defined as specific
functions that an end user of the system is expected to perform using the application, such as add or modify
a given contract.
19
Testing Plan Document
Test Objective Verify that the system and software function properly and
without error under the following stress conditions:
Completion Criteria All planned tests are executed and specified system limits are
reached / exceeded without the software or software failing
(or conditions under which system failure occurs is outside of
the specified conditions).
Special Considerations Stressing the network may require network tools to load the
network with messages / packets.
20
Testing Plan Document
system can handle for a given period. For example, if the software is processing a set of database records to
generate a report, a Volume Test would use a large test database and check that the software behaved
normally and produced the correct report.
Completion Criteria All planned tests have been executed and specified system
limits are reached / exceeded without the software or software
failing.
21
Testing Plan Document
7. Environmental Needs
7.1 Tools
Tool Version
Microsoft Word
Microsoft Excel
7.2 Software
Documentation tool Microsoft word 2007
Photoshop CS2
Design tool
Microsoft Express Web Designer
Firefox, Opera
7.3 Hardware
Client 3 laptops
2 desktops
22
Testing Plan Document
Server Reuse one 24/7 available desktop to simulate the server for testing and
deployment
8. Schedule
The testing activities and milestones are dependent on the development iterations. The Construction Phase
(in RUP-Rational Unified Process) will be split into 3 iterations. Each iteration contains a full test cycle of test
planning, designing, development, execution, and evaluation. Refer to the Software Development Plan and
the Iteration Plans for the master schedule and Construction Phase plan that shows the development
iterations.
The following table shows the Test Milestones, start date, and end date as planned.
Test Planning
Test Design
Test Development
Test Execution
Test Evaluation
Test Planning
Test Design
Test Development
Test Execution
Test Evaluation
9. Acceptance criteria
Satisfy all features will be tested as above lists. OURS Website can run smoothly. Provide a product
with functions as requirements, help customer how to use the product easily. And satisfy the following
conditions:
23
Testing Plan Document
Successful completion of all tasks as documented in the test schedule.
Quantity of medium- and low-level defects must be at an acceptable level as determined by the software
testing project team lead.
Development code reviews are complete and all issues addressed. All high-priority issues have been
resolved.
All outstanding issues pertinent to this release are resolved and closed.
All current code must be under source control, must build cleanly, the build process must be automated,
and the software components must be labeled with correct version numbers in the version control system.
All high-priority defects are corrected and fully tested prior to release.
All defects that have not been fixed before release have been reviewed by project stakeholders to confirm
that they are acceptable.
Operational procedures have been written for installation, set up, error recovery, and escalation.
10. Resources
This section presents the recommended resources for testing the Online University Registration
System, their main responsibilities, and their knowledge or skill set.
This table shows the staffing assumptions for the test activities.
Responsibilities:
24
Testing Plan Document
Management reporting
Responsibilities:
Execute tests
Log results
Document defects
Test System Ensures test environment and assets are managed and
Administrator maintained.
Responsibilities:
Responsibilities:
25
Testing Plan Document
Implementer Implements and unit tests the test classes and test
packages
Responsibilities:
System
The following table sets forth the system resources for the testing the Online University Registration System.
System Resources
Resource Description
2 Remote PCs (with internet access) PCs for connecting to OURS via
internet
26
Testing Plan Document
B- Test Case
In this part, we only provide test cases for all use cases defined in original requirement. We will complete all
test cases and use case specification of 2 new use cases have been added later in the final review.
1. Unit testing
Again, we use JUnit and EJB3Unit for unit testing. To be note that EJB3Unit is really different from JUnit or
NUnit. In JUnit and NUnit, we have to give the input and the output so that these tools can know how to
check the result and notify us whether the unit is passed or not. However, with EJB3Unit, if we test the
entities, we are not required to provide the input and the output because the EJB3Unit ( an extension of
JUnit) automatic provide an random data to check the result our entities. And all the cases we need to
check are as below checklist:
Verify the input data length specified in the database or in EJB. The EJB3Unit will can collect information
about the database basing on the entities and check the length. For example, the student name’s length is
specified is 50, then the EJB3Unit will generate data with length is 50, greater than 50, and less than 50 to
check all cases that can happen. And the case that is passed is the case with length 50. Others case is failed.
That is the reason while we do not need to write too much test case in this part. However, if the team is
required, we will do it in the review 4.
Verify the input data format specified in each form, classes, and interaction with database
String format: only accept string, not number format, or mixed (string and number) format…
Integer number format: only accept integer number format, not string format, or mixed format…
Email address format: only valid email address is accepted, other string patterns are not accepted
Date format: only date format is accepted, others are not accepted
Special character: not use special character
Empty field: empty field is not accepted.
Null: not allowed using null
Test write: test writing operation to database check whether we can write data to database or not
Test write null field: not allow write null data to our system database
Test write read: test reading and writing data with relationships and constraints
Test getter setter: test whether get and set methods of each entity
For further information about EJB3Unit and how it work, please contact with our team. This is due to the fact
that it is a brand new tool introduced after EJB3.0 is defined. And it change the way J2EE developers do the
unit test.
27
Testing Plan Document
Requirement The user is logged in correctly after providing correct username and password
Expected results The user is redirected to the specific homepage of that user
Expected results The user is redirected to the error page with a warning “You have provided invalid
username or invalid password”
2.3 Fail to login the system when providing valid username and invalid
password
Name Test case: Fail to login the system when providing valid username and invalid
password
Requirement The user is not logged in when providing valid username and invalid password
28
Testing Plan Document
Steps 1. Provide valid username in the username textbox
Expected results The user is redirected to the error page with a warning “You have provided invalid
username or invalid password”
Expected results The user is redirected to the error page with a warning “You must provide both
username and password”
2.5 Fail to login the system when providing valid username and empty
password
Name Test case: Fail to login the system when providing valid username and empty
password
Requirement The user is not logged in when providing valid username and empty password
Expected results The user is redirected to the error page with a warning “You must provide both
username and password”
29
Testing Plan Document
2.6 User account is locked after failing to log in 3 times
Name Test case: User account is locked after failing to log in 3 times
Requirement User account is locked after failing to log in 3 times with a specific username
Expected results The user is redirected to the error page with a warning “You have provided invalid
username or invalid password”
After the 3rd time, the user account with given user name is locked out and a
warning is issued “Account locked. Please wait for 30 minutes or contact the
administrator”
2.7 User logs in the system using an account is being used by another user
Name Test case: User logs in the system using an account is being used by another user
Requirement User CAN NOT log in the system using account is being used by another user
Expected results User 2 is redirected to the error page with a warning “This account is being used by
another user”
Requirement User CAN NOT log in the system using account is being locked
30
Testing Plan Document
Steps 1. Provides username of given account being locked
Expected results User is redirected to the error page with a warning “This account is being locked.
Please wait for 30 minutes or contact the administrator”
Steps 1. Choose the security question from the drop down list
Expected results The system issues the message indicates the password has been reset to the default
password “Abcd1234” and warns the user to change their password for the next log
in
2.10 User choose the wrong security question or type the wrong answer
Name Test case: User choose the wrong security question or type the wrong answer
Steps 1. Choose the wrong security question from the drop down list or
31
Testing Plan Document
2. Specify the wrong answer of the security question in the text box
Expected results The system issues the message indicates the user has chosen the wrong question or
the answer is not correct
The system redirects the user to the recover password page to choose another
question or answer the selected again
2.11 User input the empty answer for the security question
Name Test case: User input the empty answer for the security question
Steps 1. Choose the security question from the drop down list or
Expected results The system issues the message indicates the user has chosen the wrong question or
the answer is not correct
The system redirects the user to the recover password page to choose another
question or answer the selected again
Preconditions The webpage that allows user to input information of a department is displayed
32
Testing Plan Document
1. Provide department’s location in the location textbox
3.2 Fail to add a department with name that already exists in the system
Name Test case: Fail to add a department with name that already exists in the system
Preconditions The webpage that allows user to input information of a department is displayed
Steps 1. Provide department’s name (which already exist in the system) in the name
textbox
2. The user is redirected to the error page with a warning “ Fail to add the
department to the system. The name of the department that you have provided
already exists in the system”
3.3 Fail to add a department when one or some or all fields are empty
Name Test case: Fail to add a department when one or some or all fields are empty
33
Testing Plan Document
Requirement NOT all fields are filled with data
Preconditions The webpage that allows user to input information of a department is displayed
2. The user is redirected to the error page with a warning “Fail to add the
department to the system. You must provide all information”
Name Test case: Fail to add a department when inputting special character(s) to one or
some or all fields
Preconditions The webpage that allows user to input information of a department is displayed
34
Testing Plan Document
Expected results 1. The department is NOT added to the system
2. The user is redirected to the error page with a warning “Fail to add the
department to the system. Some fields contains special character(s)”
Preconditions The webpage that allows user to update information of a department is displayed
3.6 Fail to update a department with name that already exists in the system
Name Test case: Fail to update a department with name that already exists in the system
Preconditions The webpage that allows user to update information of a department is displayed
Steps 1. Provide department’s name (which already exist in the system) in the name
textbox or/and
35
Testing Plan Document
4. Provide faculty information that the department has or/and
2. The user is redirected to the error page with a warning “ Fail to update the
department in the system. The name of the department that you have provided
already exists in the system”
3.7 Fail to update a department when one or some or all fields are empty
Name Test case: Fail to update a department when one or some or all fields are empty
Preconditions The webpage that allows user to update information of a department is displayed
2. The user is redirected to the error page with a warning “Fail to update the
department in the system. You must provide all information”
36
Testing Plan Document
Name Test case: Fail to update a department when inputting special character(s) to one or
some or all fields
Preconditions The webpage that allows user to update information of a department is displayed
2. The user is redirected to the error page with a warning “Fail to update the
department in the system. Some fields contains special character(s)”
Requirement When user decides to cancel updating, the system must allow him/her to stop the
operation
Preconditions The webpage that allows user to update information of a department is displayed
37
Testing Plan Document
Expected results The department is NOT updated in the system
Requirement When user decides to delete the selected department, the system removes that
department from the system
Preconditions The webpage that allows user to delete information of a department is displayed
2. Verify that the system retrieves and displays the department information for
user and prompts message MS004 to the Academic Affair Staff to confirm
the deletion of the Department.
Expected results The system deletes the selected department from the system
Requirement When user decides to cancel deletion, the system allows user to cancel the operation
Preconditions The webpage that allows user to delete information of a department is displayed
2. Verify that the system retrieves and displays the department information for
user and prompts message MS004 to the Academic Affair Staff to confirm
the deletion of the Department.
Expected results The selected department is NOT deleted from the system
38
Testing Plan Document
Preconditions The webpage that allows user to input information of a lecturer is displayed
2. The summary of lecturer’s information has been added to the system is displayed
4.2 Fail to add a department when one or some or all fields are empty
Name Test case: Fail to add a department when one or some or all fields are empty
Preconditions The webpage that allows user to input information of a department is displayed
39
Testing Plan Document
4. Provide empty lecturer’s email address in the email textbox or/and
2. The user is redirected to the error page with a warning “Fail to add the lecturer to
the system. You must provide all information”
4.3 Fail to add a lecturer when inputting special character(s) to one or some
or all fields
Name Test case: Fail to add a lecturer when inputting special character(s) to one or some or
all fields
Preconditions The webpage that allows user to input information of a lecturer is displayed
Steps 1. Provide lecturer’s name containing special character(s) the name textbox
or/and
2. The user is redirected to the error page with a warning “Fail to add the lecturer to
40
Testing Plan Document
the system. Some fields contains special character(s)”
Requirement When user wants to update or delete a lecturer, he/she has to look for information
of the lecturer he/she wants to delete or modify information.
Preconditions The webpage that allows user to look for information of a lecturer is displayed. It can
be update or delete page.
2. Verify that the system retrieves and displays the list of lecturers of that
department
Preconditions The webpage that allows user to update information of a lecturer is displayed. (To be
noted that we have test case for looking for lecturer above already. There’s no need
to repeat it here.)
41
Testing Plan Document
Expected results 1. The lecturer is updated in the system
42
Testing Plan Document
4.6 Fail to update a lecturer when one or some or all fields are empty
Name Test case: : Fail to update a lecturer when one or some or all fields are empty
Preconditions The webpage that allows user to update information of a lecturer is displayed.(To be
noted that we have test case for looking for lecturer above already. There’s no need
to repeat it here.)
2. The user is redirected to the error page with a warning “Fail to update the
lecturer in the system. You must provide all information”
Name Test case: Fail to update a lecturer information when inputting special character(s) to
one or some or all fields
Preconditions The webpage that allows user to update information of a lecturer is displayed. (To be
noted that we have test case for looking for lecturer above already. There’s no need
to repeat it here.)
43
Testing Plan Document
Steps 1. Provide empty lecturer’s name containing special character(s) in the name
textbox or/and
2. The user is redirected to the error page with a warning “Fail to update the
lecturer in the system. Some fields contains special character(s)”
Requirement When user decides to cancel updating, the system must allow him/her to stop the
operation
Preconditions The webpage that allows user to update information of a lecturer is displayed. (To be
noted that we have test case for looking for lecturer above already. There’s no need
to repeat it here.)
44
Testing Plan Document
Requirement When user decides to delete the selected lecturer, the system removes that lecturer
from the system
Preconditions The webpage that allows user to delete information of a lecturer is displayed. (To be
noted that we have test case for looking for lecturer above already. There’s no need
to repeat it here.)
Expected results The system deletes the selected lecturer from the system
Requirement When user decides to cancel deletion, the system allows user to cancel the operation
Preconditions The webpage that allows user to delete information of a lecturer is displayed. (To be
noted that we have test case for looking for lecturer above already. There’s no need
to repeat it here.)
Expected results The selected lecturer is NOT deleted from the system
45
Testing Plan Document
Preconditions The webpage that allows user to input information of a student is displayed
2. The summary of student’s information has been added to the system is displayed
5.2 Fail to add a student when one or some or all fields are empty
Name Test case: Fail to add a student when one or some or all fields are empty
Preconditions The webpage that allows user to input information of a student is displayed
46
Testing Plan Document
4. Choose empty student’s academic duration in the range list or/and
2. The user is redirected to the error page with a warning “Fail to add the student to
the system. You must provide all information”
5.3 Fail to add a student when inputting special character(s) to one or some
or all fields
Name Test case: Fail to add a student when inputting special character(s) to one or some or
all fields
Preconditions The webpage that allows user to input information of a lecturer is displayed
Steps 1. Provide student’s name containing special character(s) the name textbox
or/and
2. The user is redirected to the error page with a warning “Fail to add the student to
47
Testing Plan Document
the system. Some fields contains special character(s)”
Requirement User wants to find information of a specific student with student’s ID or list of
students with given name.
Steps 1. Chooses ID and Name filter from the filter drop down list
Expected results The information of student with given ID or a list of student(s) with given name is
displayed
Name Test case: Fail to search student by student ID or/and by student name when
providing invalid student ID or/and student name
Requirement User wants to find information of student whose ID or/and name does not exist in
the system, then the system must notify the user about this
Steps 1. Chooses ID and Name filter from the filter drop down list
Expected results The user is redirected to the error page with a warning “The desired student is not
found”
48
Testing Plan Document
Name Test case: Fail to search student by student ID or/and by student name when
providing empty student ID or/and student name
Requirement User wants to find information of a specific student’s ID or list of students with given
name.
Steps 1. Chooses ID and Name filter from the filter drop down list
Expected results The user is redirected to the error page with a warning “You must provide an ID
or/and student name”
Requirement User wants to view tuition fee information of students of a specific faculty with a
specific academic duration
Preconditions The webpage allows user to view tuition fee of students is displayed
Steps 1. Chooses faculty and academic duration filter from the filter drop down list
49
Testing Plan Document
Expected results The information of students of selected faculty with specific academic duration
50
Testing Plan Document
5.8 Search student by academic year, semester, and course
Name Test case: Search student by academic year, semester, and course
Requirement User wants to find information of students in a specific academic year and/or
semester and/or course
Steps 1. Chooses academic year, semester, and course filter from the filter drop
down list
2. Choose a academic year from the academic year drop down list or/and
Expected results The information of students of selected academic year and/or semester and/or
course is displayed
Preconditions The webpage that allows user to update information of a student is displayed. (To be
noted that we have test cases searching for student above already. There’s no need
to repeat it here)
51
Testing Plan Document
8. Click on update button
5.10 Fail to update a student when one or some or all fields are empty
Name Test case: Fail to update a student when one or some or all fields are empty
Preconditions The webpage that allows user to update information of a student is displayed (To be
noted that we have test cases searching for student above already. There’s no need
to repeat it here)
2. The user is redirected to the error page with a warning “Fail to update the student
in the system. You must provide all information”
Name Test case: Fail to update a student information when inputting special character(s) to
one or some or all fields
52
Testing Plan Document
Requirement All fields are filled with data
Preconditions The webpage that allows user to update information of a student is displayed. (To be
noted that we have test cases searching for student above already. There’s no need
to repeat it here)
2. The user is redirected to the error page with a warning “Fail to update the student
in the system. Some fields contains special character(s)”
Requirement When user decides to cancel updating, the system must allow him/her to stop the
operation
Preconditions The webpage that allows user to update information of a student is displayed. (To be
noted that we have test cases searching for student above already. There’s no need
to repeat it here.)
53
Testing Plan Document
5.13 Delete a student
Requirement When user decides to delete the selected student, the system removes that student
from the system
Preconditions The webpage that allows user to delete information of a student is displayed. (To be
noted that we have test cases searching for student above already. There’s no need
to repeat it here.)
Expected results The system deletes the selected student from the system
Requirement When user decides to cancel deletion, the system allows user to cancel the operation
Preconditions The webpage that allows user to delete information of a student is displayed. (To be
noted that we have test cases searching for student above already. There’s no need
to repeat it here)
Expected results The selected student is NOT deleted from the system
54
Testing Plan Document
Requirement The new course offering is created and distributed to the students
4. Click on the check box to choose the subject which is selected to offer
5. Click on the drop down list to choose the lecturers for the selected courses
6. Click on the Submit button to create the list of course offering for the
selected faculty
The system displayed the list of course offering that has been created
55
Testing Plan Document
3. Click on the drop down list to choose the desired faculty
4. Check or uncheck the check box of each course to change the list of course
offering
The list of course offering is updated with the changes of the user
The updated list of course offering is displayed after the operation completed
Name Test case: Cancel during the Add list of course offering operation
4. Click on the check box to choose the subject which is selected to offer
5. Click on the drop down list to choose the lecturers for the selected courses
6. Click on the Submit button to create the list of course offering for the
selected faculty
56
Testing Plan Document
Name Test case: Cancel during the Update list of course offering operation
4. Check or uncheck the check box of each course to change the list of course
offering
Name Test case: The user creates an empty list of course offering
4. Don’t click any check box in order not to select any course
57
Testing Plan Document
5. Click on the drop down list to choose the lecturers for the selected courses
6. Click on the Submit button to create the list of course offering for the
selected faculty
The system issued warning about the empty list of course offering
The system redirects to the Create list of course offering and let the user to create
the non – empty list
6.6 Update list of course offering while there’s no list of course offering for
specific faculty
Name Test case: Update list of course offering while there’s no list of course offering for
specific faculty
58
Testing Plan Document
Name Test case: View tuition fee by student ID or/and by student name
Requirement User wants to view tuition fee information of a specific student or list of students
with given name.
Preconditions The webpage allows user to view tuition fee of students is displayed
Steps 1. Chooses ID and Name filter from the filter drop down list
Expected results The tuition fee information of student with given ID or student(s) with given name is
displayed
7.2 Fail to view tuition fee by student ID or/and by student name when
providing invalid student ID or/and student name
Name Test case: Fail to view tuition fee by student ID or/and by student name when
providing invalid student ID or/and student name
Requirement User wants to view tuition fee information of student whose ID or/and name does
not exist in the system, then the system must notify the user about this
Preconditions The webpage allows user to view tuition fee of students is displayed
Steps 1. Chooses ID and Name filter from the filter drop down list
59
Testing Plan Document
Expected results The user is redirected to the error page with a warning “The desired student is not
found”
7.3 Fail to view tuition fee by student ID or/and by student name when
providing empty student ID or/and student name
Name Test case: Fail to view tuition fee by student ID or/and by student name when
providing empty student ID or/and student name
Requirement User wants to view tuition fee information of a specific student or list of students
with given name.
Preconditions The webpage allows user to view tuition fee of students is displayed
Steps 1. Chooses ID and Name filter from the filter drop down list
Expected results The user is redirected to the error page with a warning “You must provide an ID
or/and student name”
Name Test case: View tuition fee by faculty or/and by academic duration
Requirement User wants to view tuition fee information of students of a specific faculty with a
specific academic duration
Preconditions The webpage allows user to view tuition fee of students is displayed
Steps 1. Chooses faculty and academic duration filter from the filter drop down list
60
Testing Plan Document
Expected results The tuition fee information of students of selected faculty with specific academic
duration
Name Test case: View tuition fee by academic year, semester, and course
Requirement User wants to view tuition fee information of students in a specific academic year
and/or semester and/or course
Preconditions The webpage allows user to view tuition fee of students is displayed
Steps 1. Chooses academic year, semester, and course filter from the filter drop
down list
2. Choose a academic year from the academic year drop down list or/and
Expected results The tuition fee information of students of selected academic year and/or semester
and/or course is displayed
Requirement User wants to update the tuition fee status of students after he/she pays the tuition
fee. User wants to update tuition fee status of student that user has update wrongly.
Preconditions The webpage allows user to update the tuition fee status of student is
displayed.(Because we have the test cases for filtering student to find the student(s)
above, we do not need to repeat steps of filtering here). And list of students with
tuition fee status is displayed.
2. Change status of tuition fee of that student by choose tuition fee status from
61
Testing Plan Document
the stats drop down list
Expected results Tuition fee status of selected student is changed and the system notify the user.
Steps 1. Assume that we are in View Academic History function of the system.
2. Choose a filter group: View All, View by specific year and semester, View by
passed and failed status.
62
Testing Plan Document
Steps 1. Choose “All” filter from drop down list.
Expected results The information of all courses he/she has taken is displayed.
Requirement Student wants to view all courses information of specific year or/and semester.
Steps 1. Choose “Specific year and Semester” filter from drop down list.
Expected results The information of all courses he/she has taken is displayed.
Requirement Student wants to view all courses information of passed and failed status.
Steps 1. Choose “passed and failed status” filter from drop down list.
Expected results The information of all courses he/she has taken is displayed.
63
Testing Plan Document
Requirement A student just register any course opened by his/her faculty.
In addition, this course has all prerequisites are studied in this student's academic
history.
Each subject may require the student to finish one or more subjects
2. Select the course offering to add from list of available course offerings
3. Check the check box to select the course, which include more than 30 credits
Expected results The system prompts the message “You cannot register more than 30 credits”
In addition, this course has all prerequisites are studied in this student's academic
history.
Each subject may require the student to finish one or more subjects
2. Select the course offering to add from list of available course offerings
3. Check the check box to select the course, select less than 15 credits
64
Testing Plan Document
4. Click on the Register button
Expected results The system prompts the message “You cannot register less than 15 credits”
In addition, this course has all prerequisites are studied in this student's academic
history.
Each subject may require the student to finish one or more subjects
3. Select course offering from a list of available course offerings of this student.
Note that the total of credits is selected greater or equal 15 and less or equal
30.
65
Testing Plan Document
In addition, this course has all prerequisites are studied in this student's academic history.
Each subject may require the student to finish one or more subjects
3. Select Programming Language course from the list of available course offerings to
add.
4. Deselect Web Programming course from the existing schedule to drop. Note that
we can add or drop free, but we must satisfy the total of credits of the system.
C- Appendix
Message
Type Context Error Messages Actions
ID
66
Testing Plan Document
Account locked. Please wait for 30
MS002 Info Account locked OK
minutes or contact the administrator.
MS009 Info Student not found The selected student does not exist OK
MS014 Info Register more than 30 You cannot register more than 30 OK
67
Testing Plan Document
credits credits
D- Inspection Checklist
Are there any features that are planned for testing but should be excluded?
Feasibility
Can the testing as planned be accomplished within the known cost and schedule constraints?
Environment
Is the test plan traceable to any nonfunctional requirements that define the operating environment?
Performance
Does the test plan account for the expected load for concurrent users, large databases, or other
performance requirements?
Acceptance Criteria
Does each test case describe the interaction using specific user interface and data elements?
Completeness
Is every requirement in the SRS verified fully with individual test cases?
Accuracy
For every behavior in the requirement, is there a verification of the actual behavior?
Is the test case data specific if data must be entered or modified, is that data provided?
Traceability
69