Document

1. Testing Plan & Test case Document
12/7/2007
Ho Chi Minh National University – International University
Instructor: Phan Viet Hoang
Group 6
Date December 7th , 2007
Version 1.0
Status Baseline
Author Team TiHonMumMim
Reviewer Team TiHonMumMim
Documenter Nguyen Duc Quan
Team member Signature
Nguyen Duc Quan
Le Vu Hoang
Tran Minh Phung
Phan Duy Tan
Huynh Da Thuc

2. Testing Plan Document
Table of Contents
A- Test Plan .......................................................................................................................................................7
1. Introduction .................................................................................................................................................7
1.1 Purpose ................................................................................................................................................7
1.2 Scope ....................................................................................................................................................7
1.3 References ...........................................................................................................................................7
2. Review requirement and Design ..................................................................................................................7
2.1 Review requirement ............................................................................................................................7
2.2 Review system architecture .................................................................................................................9
3. Features to be tested ................................................................................................................................ 12
4. Features not to be tested ......................................................................................................................... 13
5. Approach ................................................................................................................................................... 13
5.1 Kind of test ........................................................................................................................................ 13
5.1.1 Data and Database Integrity Testing......................................................................................... 13
5.1.2 System testing ........................................................................................................................... 14
5.1.3 Performance Testing ................................................................................................................. 14
5.1.4 Load Testing .............................................................................................................................. 14
5.1.5 Stress Testing ............................................................................................................................ 14
5.1.6 Volume Testing ......................................................................................................................... 14
5.2 Test Strategy ..................................................................................................................................... 15
5.2.1 Checklist of unit test ................................................................................................................. 15
5.2.2 Unit testing................................................................................................................................ 15
5.2.3 Smoke test ................................................................................................................................ 16
5.2.4 Test Automation ....................................................................................................................... 16
5.2.5 Data and Database Integrity Testing......................................................................................... 16
5.2.6 System Testing .......................................................................................................................... 17
5.2.7 Performance Testing ................................................................................................................. 17
2

3. 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
6.1 Suspension criteria ............................................................................................................................ 21
6.2 Resumption requirements ................................................................................................................ 21
7. Environmental Needs................................................................................................................................ 22
7.1 Tools .................................................................................................................................................. 22
7.2 Software ............................................................................................................................................ 22
7.3 Hardware .......................................................................................................................................... 22
8. Schedule .................................................................................................................................................... 23
9. Acceptance criteria ................................................................................................................................... 23
10. Resources .................................................................................................................................................. 24
B- Test Case ................................................................................................................................................... 27
1. Unit testing................................................................................................................................................ 27
2. Test Cases of Log in and Log out Use Case ............................................................................................... 28
2.1 User logs in successfully with valid username and password........................................................... 28
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.6 User account is locked after failing to log in 3 times ........................................................................ 30
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.9 Recover the password....................................................................................................................... 31
2.10 User choose the wrong security question or type the wrong answer.............................................. 31
3

4. Testing Plan Document
2.11 User input the empty answer for the security question................................................................... 32
3. Test Cases of Manage Department Information Use case ....................................................................... 32
3.1 Add a department with valid information successfully .................................................................... 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.5 Update a department with valid information successfully ............................................................... 35
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
3.9 Update cancel ................................................................................................................................... 37
3.10 Delete a department ......................................................................................................................... 38
3.11 Delete cancel..................................................................................................................................... 38
4. Test Cases of Manage Lecturer Information use case .............................................................................. 39
4.1 Add a lecturer with valid information successfully ........................................................................... 39
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.4 Look for a lecturer ............................................................................................................................. 41
4.5 Update a lecturer with valid information successfully ..................................................................... 41
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.8 Update cancel ................................................................................................................................... 44
4.9 Delete a lecturer ............................................................................................................................... 44
4.10 Delete cancel..................................................................................................................................... 45
5. Test Cases of Manage Student Information Use Case .............................................................................. 46
4

5. 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.4 Search student by student ID or/and by student name ................................................................... 48
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.7 Search student by student ID or/and by student name ................................................................... 49
5.8 Search student by academic year, semester, and course................................................................. 51
5.9 Update a student with valid information successfully...................................................................... 51
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
5.12 Update is canceled ............................................................................................................................ 53
5.13 Delete a student................................................................................................................................ 54
5.14 Delete is canceled ............................................................................................................................. 54
6. Test Case of Manage Course Offering Use Case ....................................................................................... 55
6.1 The user create a new course offering ............................................................................................. 55
6.2 Update the list of course offering ..................................................................................................... 55
6.3 Cancel during the Add list of course offering operation................................................................... 56
6.4 Cancel during the Update list of course offering operation ............................................................. 57
6.5 The user creates an empty list of course offering ............................................................................ 57
6.6 Update list of course offering while there’s no list of course offering for specific faculty............... 58
7. Test Case of Manage Financial Activities Use Case................................................................................... 59
7.1 View tuition fee by student ID or/and by student name .................................................................. 59
5

6. 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.4 View tuition fee by faculty or/and by academic duration ................................................................ 60
7.5 View tuition fee by academic year, semester, and course ............................................................... 61
7.6 Update tuition fee status of a student.............................................................................................. 61
8. Test Case of View Academic History Use Case ......................................................................................... 62
8.1 Views all course have taken history. ................................................................................................. 62
8.2 View by specific year and semester. ................................................................................................. 63
8.3 View by passed and failed status. ..................................................................................................... 63
9. Test Case of Register Course Use Case ..................................................................................................... 63
9.1 User register more than 30 credits ................................................................................................... 63
9.2 User selects less than 15 credits ....................................................................................................... 64
9.3 Confirm registration of course offering. ........................................................................................... 65
9.4 Confirm updating course offering. .................................................................................................... 66
C- Appendix ................................................................................................................................................... 66
D- Inspection Checklist .................................................................................................................................. 68
1. The following checklist items apply to the test plan. ............................................................................... 68
2. The following checklist items apply to the test cases: .............................................................................. 69
6

7. 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.
List the recommended test requirements (high level).
Recommend and describe the testing strategies.
Identify the required resources, provide an estimate of the test efforts, and detail testing schedule.
List the deliverable elements of the test activities.
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
Business Plan and SRS document
2. Review requirement and Design
2.1 Review requirement
Original requirement defined by our team is that our system only contains 8 use cases. You can see in the
original use case model below.
7

8. 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.
The following is the updated use case model.
8

9. Testing Plan Document
2.2 Review system architecture
From the updated requirement, our team sees that the number of functions the system provides is
too large in comparison with the scope of the system. This brings us to the decision to divide the original
system into many subsystems as follow.
9

10. Testing Plan Document
System architecture with sub-system model
System architecture with layer model
10

11. Testing Plan Document
11

12. 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
User login and logout
Login
Logout
Recovery password
View Academic History (depend on filter selected by user)
Register for course
Manage Department Information
Add a department
Update a department
Delete a department
Viewing information
Manage Student Information
Add a student
Update a student
Delete a student
Search for student(s) (for viewing or updating or deleting)
Manage Lecturer Information
Add a lecturer
Update a lecturer
Delete a lecturer
Viewing information
Manage Course Catalog
12

13. 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)
Manage Offering Courses
Create list of course offering
Update list of course offering
Add a course offering
Delete a course offering
Change lecturer of a course offering
Manage Financial Activities
View tuition fee information of student(s)
Update tuition fee status of student(s)
Manage User Account
(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.
4. Features not to be tested
Because we will test all features of the system we have been defined, there is no feature that will
not be tested.
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.
5.1.1 Data and Database Integrity Testing
Data integrity and database integrity test techniques verify that data is being stored by the system in
a manner where the data is not compromised by updating, restoration, or retrieval processing. This type of
testing is intended to uncover design flaws that may result in data corruption, unauthorized data access, lack
of data integrity across multiple tables, and lack of adequate transaction performance. The database, data
files, and the database or data file processes should be tested as a subsystem within the application.
13

14. Testing Plan Document
5.1.2 System testing
System testing of software is testing conducted on a complete, integrated system to evaluate the
system's compliance with its specified requirements. They includes the following functions
User login and logout
View Academic History
Register for course
Manage Department Information
Manage Student Information
Manage Lecturer Information
Manage Course Catalog
Manage Offering Courses
Manage Financial Activities
Manage User Account
5.1.3 Performance Testing
Performance Testing covers a broad range of engineering or functional evaluations where a
material, product, or system is not specified by detailed material or component specifications: Rather,
emphasis is on the final measurable performance characteristics.
5.1.4 Load Testing
Load testing is the process of creating demand on a system or device and measuring its response.
5.1.5 Stress Testing
Stress testing is a form of testing that is used to determine the stability of a given system or entity. It
involves testing beyond normal operational capacity, often to a breaking point, in order to observe the
results. Stress testing may have a more specific meaning in certain industries.
Verify system response during maximum student logins.
5.1.6 Volume Testing
Volume Testing belongs to the group of non-functional tests, which are often misunderstood and/or
used interchangeably. Volume testing refers to testing a software application for a certain data volume.
Verify system response when Course Catalog Database at 90% capacity.
14

15. 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.
5.2.1 Checklist of unit test
Verify the input data length specified in the database or in EJB
Verify the input data format specified in each form, classes, and interaction with database
String format
Integer number format
Email address format
Date format
Special character
Empty field
Null
Test write
Test write null field
Test write read
Test getter setter
Doing this kind of checking help us to decrease the number of simple test cases
5.2.2 Unit testing
According to the system architecture, we have to test all entities, ejb3 session bean, struts actions…
In order to complete this kind of test, we will use JUnit and EJB3Unit as tools for implement and execute the
unit test.
15

16. 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:
Login and Logout use case
Manage courses offering user case
Register for courses use case
For the detail of each test case, please reference to the part of test case in later part.
5.2.4 Test Automation
Test automation is the use of software to control the execution of tests, the comparison of actual outcomes
to predicted outcomes, the setting up of test preconditions, and other test control and test reporting
functions.
All the tools that are used for test automation please reference to the part of tools in later part.
5.2.5 Data and Database Integrity Testing
The database data and database processing should be tested as separate systems. These systems should be
tested without the applications (as the interface to the data). Additional research into the DBMS needs to be
performed to identify the tools / techniques that may exist to support the testing identified below.
Ensure Database access methods and processes function properly and
Test Objective
without data corruption.
Invoke each database access method and process, seeding each with valid
Technique
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)
All database access methods and processes function as designed and without
Completion Criteria
any data corruption.
Testing may require a DBMS development environment or drivers to enter or
Special Considerations
modify data directly in the databases.
Processes should be invoked manually.
Small or minimally sized databases (limited number of records) should be
16

17. Testing Plan Document
used to increase the visibility of any non-acceptable events.
5.2.6 System Testing
Testing of the application should focus on any target requirements that can be traced directly to use cases
(or business functions), and business rules. The goals of these tests are to verify proper data acceptance,
processing, and retrieval, and the appropriate implementation of the business rules. This type of testing is
based upon black box technique, which is, verifying the application (and its internal processes) by interacting
with the application via the GUI and analyzing the output (results). Identified below is an outline of the
testing recommended for each application?
Ensure proper application navigation, data entry, processing, and
Test Objective
retrieval.
Execute each use case, use case flow, or function, using valid and
Technique
invalid data, to verify the following:
The expected results occur when valid data is used.
The appropriate error / warning messages are displayed when invalid
data is used.
Each business rule is properly applied.
Completion Criteria All planned tests have been executed.
All identified defects have been addressed.
Access to the OURS Server and the existing Course Catalog System is
Special Considerations
required.
5.2.7 Performance Testing
Performance testing measures response times, transaction rates, and other time sensitive
requirements. The goal of Performance testing is to verify and validate the performance requirements have
been achieved. Performance testing is usually executed several times, each using a different quot;background
loadquot; on the system. The initial test should be performed with a quot;nominalquot; load, similar to the normal load
experienced (or anticipated) on the target system. A second performance test is running using a peak load.
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

18. Testing Plan Document
NOTE: Transactions below refer to quot;logical business transactionsquot;. 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.
Validate System Response time for designated transactions or business
Test Objective
functions under a the following two conditions:
- Normal anticipated volume
- Anticipated worse case volume
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).
Single Transaction / single user: Successful completion of the test scripts
Completion Criteria
without any failures and within the expected / required time allocation (per
transaction)
Multiple transactions / multiple users: Successful completion of the test
scripts without any failures and within acceptable time allocation.
Comprehensive performance testing includes having a quot;backgroundquot; load
Special Considerations:
on the server. There are several methods that can be used to perform this,
including:
quot;Drive transactionsquot; directly to the server, usually in the form of MySQL
calls.
Create quot;virtualquot; user load to simulate many (usually several hundred)
clients. Remote Terminal Emulation tools are used to accomplish this load.
This technique can also be used to load the network with quot;traffic.quot;
Use multiple physical clients, each running test scripts to place a load on
the system.
Performance testing should be performed on a dedicated machine or at a
dedicated time. This permits full control and accurate measurement.
The databases used for Performance testing should be either actual size, or
18

19. Testing Plan Document
scaled equally.
5.2.8 Load Testing
Load testing measures subjects the system-under-test to varying workloads to evaluate the system's
ability to continue to function properly under these different workloads. The goal of load testing is to
determine and ensure that the system functions properly beyond the expected maximum workload.
Additionally, load testing evaluates the performance characteristics (response times, transaction rates, and
other time sensitive issues).
NOTE: Transactions below refer to quot;logical business transactionsquot;. 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.
Verify System Response time for designated transactions or
Test Objective
business cases under varying workload conditions.
Technique Use tests developed for Business Cycle Testing.
Modify data files (to increase the number of transactions) or
the tests to increase the number of times each transaction
occurs.
Multiple transactions / multiple users: Successful completion of
Completion Criteria
the tests without any failures and within acceptable time
allocation.
Load testing should be performed on a dedicated machine or
Special Considerations
at a dedicated time. This permits full control and accurate
measurement.
The databases used for load testing should be either actual
size, or scaled equally.
5.2.9 Stress Testing
Stress testing is intended to find errors due to low resources or competition for resources. Low
memory or disk space may reveal defects in the software that aren't apparent under normal conditions.
Other defects might results from competition for shared resource like database locks or network bandwidth.
Stress testing identifies the peak load the system can handle.
NOTE: References to transactions below refer to logical business transactions.
19

20. Testing Plan Document
Verify that the system and software function properly and
Test Objective
without error under the following stress conditions:
little or no memory available on the server (RAM)
Maximum (actual or physically capable) number of clients
connected (or simulated)
Multiple users performing the same transactions against the
same data / accounts
Worst-case transaction volume / mix (see performance testing
above).
NOTES: Stress testing's goal might also be stated as identify
and document the conditions under which the system FAILS to
continue functioning properly.
Technique Use tests developed for Performance Testing.
To test limited resources, tests should be run on single
machine, RAM and DASD on server should be reduced (or
limited).
For remaining stress tests, multiple clients should be used,
running either the same tests or complementary tests to
produce the worst-case transaction volume / mix.
All planned tests are executed and specified system limits are
Completion Criteria
reached / exceeded without the software or software failing
(or conditions under which system failure occurs is outside of
the specified conditions).
Stressing the network may require network tools to load the
Special Considerations
network with messages / packets.
The DASD used for the system should temporarily be reduced
to restrict the available space for the database to grow.
Synchronization of the simultaneous clients accessing of the
same records / data accounts.
5.2.10 Volume Testing
Volume Testing subjects the software to large amounts of data to determine if limits are reached
that cause the software to fail. Volume testing also identifies the continuous maximum load or volume the
20

21. 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.
Verify that the application / system successfully functions
Test Objective
under the following high volume scenarios:
Maximum (actual or physically capable) number of clients
connected (or simulated) all performing the same, worst case
(performance) business function for an extended period.
Maximum database size has been reached (actual or scaled)
and multiple queries / report transactions are executed
simultaneously.
Technique Use tests developed for Performance Testing.
Multiple clients should be used, either running the same tests
or complementary tests to produce the worst case transaction
volume / mix (see stress test above) for an extended period.
Maximum database size is created (actual, scaled, or filled with
representative data) and multiple clients used to run queries /
report transactions simultaneously for extended periods.
All planned tests have been executed and specified system
Completion Criteria
limits are reached / exceeded without the software or software
failing.
What period of time would be considered an acceptable time
Special Considerations
for high volume conditions (as noted above)?
6. Suspension criteria and resumption requirements
6.1 Suspension criteria
Three use cases have more than 2 major errors or fours minor errors, then the build is not acceptable and
the testing is suspended.
6.2 Resumption requirements
All major errors & and at least 70% of minor errors that have been found in previous iteration are fixed
21

22. Testing Plan Document
7. Environmental Needs
7.1 Tools
Tool Version
Performance Testing AdventnetQEngin WebTest Last version
Project Management Microsoft Project Last version
Microsoft Word
Microsoft Excel
DBMS tools MySQL GUI 5.0
7.2 Software
Documentation tool Microsoft word 2007
Scheduling tool Microsoft project 2007
IDE Netbean 6.0
Web Server Glassfish server 2.0
Photoshop CS2
Design tool
Microsoft Express Web Designer
JDK JDK 6.0
DBMS MySQL 5.0
Browser Internet Explorer 6.0, 7.0
Firefox, Opera
Operating system Windows XP, Vista, Linux
7.3 Hardware
Client 3 laptops
2 desktops
22

23. Testing Plan Document
Reuse one 24/7 available desktop to simulate the server for testing and
Server
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.
Milestone Task Start Date End Date
Iteration C1: Review 3 9th November 7th December
Test Planning
Test Design
Test Development
Test Execution
Test Evaluation
Iteration C2: Review 4 7th December 28th December
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

24. 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.
User interfaces for all features are functionally complete.
Installation documentation and scripts are complete and tested.
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.
The end user experience is at an agreed acceptable level.
Operational procedures have been written for installation, set up, error recovery, and escalation.
There must be no adverse effects on already deployed systems.
10. Resources
This section presents the recommended resources for testing the Online University Registration
System, their main responsibilities, and their knowledge or skill set.
Roles and responsibilities
This table shows the staffing assumptions for the test activities.
Worker Specific Responsibilities/Comments
Test Manager Provides management oversight
Responsibilities:
Provide technical direction
Acquire appropriate resources
24

25. Testing Plan Document
Management reporting
Test Designer Identifies, prioritizes, and implements test cases
Responsibilities:
Generate test plan
Generate Test Suite
Evaluate effectiveness of test effort
System Tester Executes the tests, Responsibilities:
Execute tests
Log results
Recover from errors
Document defects
Test System Ensures test environment and assets are managed and
Administrator maintained.
Responsibilities:
Administer test management system
Install / manage worker access to test systems
Database Ensures test data (database) environment and assets are
Administration managed and maintained.
Database Manager
Responsibilities:
Administer test data (database)
Identifies and defines the operations, attributes, and
Designer
associations of the test classes
Responsibilities:
25

26. Testing Plan Document
Identifies and defines the test class(es)
Identifies and defines the test packages
Implements and unit tests the test classes and test
Implementer
packages
Responsibilities:
Creates the test classes and packages implemented in the
Test Suite.
System
The following table sets forth the system resources for the testing the Online University Registration System.
System Resources
Resource Description
Server for simulating the environment
OURS Server
of real OURS system
Course Catalog Database Simulated database
PCs for connecting to OURS via
2 Remote PCs (with internet access)
internet
2 Local PCs (connected via LAN) Local network computers
Test Development PC's - 2
Simulator for load and performance
Load Simulator
test
26

27. 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.
Other kinds of checks will be showed below:
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

28. Testing Plan Document
2. Test Cases of Log in and Log out Use Case
2.1 User logs in successfully with valid username and password
Name Test case: User logs in successfully with valid username and password
Requirement The user is logged in correctly after providing correct username and password
Preconditions The user is at the homepage or the log in page
Steps 1. Provide valid username in the username textbox
2. Provide valid password in the password textbox
3. Click on log in button
Expected results The user is redirected to the specific homepage of that user
2.2 Fail to login the system when providing invalid username
Name Test case: Fail to login the system when providing invalid username
Requirement The user is not logged in when providing invalid username
Preconditions The user is at the homepage or the log in page
Steps 1. Provide invalid username in the username textbox
2. Provide password in the password textbox or let password field be empty
3. Click on log in button
The user is redirected to the error page with a warning “You have provided invalid
Expected results
username or invalid password”
2.3 Fail to login the system when providing valid username and invalid
password
Test case: Fail to login the system when providing valid username and invalid
Name
password
Requirement The user is not logged in when providing valid username and invalid password
Preconditions The user is at the homepage or the log in page
28

29. Testing Plan Document
Steps 1. Provide valid username in the username textbox
2. Provide invalid password in the password textbox
3. Click on log in button
The user is redirected to the error page with a warning “You have provided invalid
Expected results
username or invalid password”
2.4 Fail to login the system when providing empty username
Name Test case: Fail to login the system when providing empty username
Requirement The user is not logged in when providing empty username
Preconditions The user is at the homepage or the log in page
Steps 1. Provide empty username in the username textbox
2. Provide password in the password textbox or let password field be empty
3. Click on log in button
The user is redirected to the error page with a warning “You must provide both
Expected results
username and password”
2.5 Fail to login the system when providing valid username and empty
password
Test case: Fail to login the system when providing valid username and empty
Name
password
Requirement The user is not logged in when providing valid username and empty password
Preconditions The user is at the homepage or the log in page
Steps 1. Provide valid username in the username textbox
2. Provide empty password in the password textbox
3. Click on log in button
The user is redirected to the error page with a warning “You must provide both
Expected results
username and password”
29

30. 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
Preconditions The user is at the homepage or the log in page
Steps 1. Provide valid username in the username textbox or/and
2. Provide invalid or empty password in the password textbox
3. Click on log in button
4. Repeat above process for 3 times
The user is redirected to the error page with a warning “You have provided invalid
Expected results
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
Preconditions A given account is being used by user 1
Steps 1. User 2 provides username of user 1 exactly
2. User 2 provides password of user 1 exactly
3. Click on log in button
User 2 is redirected to the error page with a warning “This account is being used by
Expected results
another user”
2.8 User logs in the system using an account is being locked
Name Test case: User logs in the system using an account is being locked
Requirement User CAN NOT log in the system using account is being locked
Preconditions A given account is being locked by logging in fail 3 times
30

31. Testing Plan Document
Steps 1. Provides username of given account being locked
2. Provide password of given account being locked
3. Click on log in button
User is redirected to the error page with a warning “This account is being locked.
Expected results
Please wait for 30 minutes or contact the administrator”
2.9 Recover the password
Name Test case: Recover the password
Requirement The user lost or forget the password
Preconditions The user clicks on the “Forget password”
The system warns the user about recovering the password
Steps 1. Choose the security question from the drop down list
2. Specify the answer of the security question in the text box
3. Click on the Recovery password button
The system issues the message indicates the password has been reset to the default
Expected results
password “Abcd1234” and warns the user to change their password for the next log
in
The password is reset to the default password “Abcd1234”
The system redirects the user to the log in page
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
Requirement The user lost or forget the password
Preconditions The user clicks on the “Forget password”
The system warns the user about recovering the password
Steps 1. Choose the wrong security question from the drop down list or
31

32. Testing Plan Document
2. Specify the wrong answer of the security question in the text box
3. Click on the Recovery password button
The system issues the message indicates the user has chosen the wrong question or
Expected results
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
Requirement The user lost or forget the password
Preconditions The user clicks on the “Forget password”
The system warns the user about recovering the password
Steps 1. Choose the security question from the drop down list or
2. Leave the answer text box blank
3. Click on the Recovery password button
The system issues the message indicates the user has chosen the wrong question or
Expected results
the answer is not correct
The system redirects the user to the recover password page to choose another
question or answer the selected again
3. Test Cases of Manage Department Information Use case
3.1 Add a department with valid information successfully
Name Test case: Add a department with valid information successfully
Requirement All fields are filled with valid data
Preconditions The webpage that allows user to input information of a department is displayed
Steps Provide department’s name in the name textbox
32

33. Testing Plan Document
1. Provide department’s location in the location textbox
2. Provide department’s dean in the dean textbox
3. Provide faculty information that the department has
4. Provide department description in the description text area
5. Click on add button
Expected results 1. The department is added to the system
2. The summary of department has been added to the system is displayed
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
Requirement All fields are filled with data
Preconditions The webpage that allows user to input information of a department is displayed
1. Provide department’s name (which already exist in the system) in the name
Steps
textbox
2. Provide department’s location in the location textbox
3. Provide department’s dean in the dean textbox
4. Provide faculty information that the department has
5. Provide department description in the description text area
6. Click on add button
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. 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

34. 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
Steps 1. Provide empty department’s name in the name textbox or/and
2. Provide empty department’s location in the location textbox or/and
3. Provide empty department’s dean in the dean textbox or/and
4. Provide empty faculty information that the department has or/and
5. Provide department description in the description text area or/and
6. Click on add button
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. You must provide all information”
3.4 Fail to add a department when inputting special character(s) to one or
some or all fields
Test case: Fail to add a department when inputting special character(s) to one or
Name
some or all fields
Requirement All fields are filled with data
Preconditions The webpage that allows user to input information of a department is displayed
1. Provide department’s name containing special character(s) in the name
Steps
textbox or/and
2. Provide department’s location containing special character(s) in the location
textbox or/and
3. Provide department’s dean containing special character(s) in the dean
textbox or/and
4. Provide faculty information containing special character(s) or/and
5. Provide department description containing special character(s) in the
description text area or/and
6. Click on add button
34

35. 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)”
3.5 Update a department with valid information successfully
Name Test case: Update a department with valid information successfully
Requirement All fields are filled with valid data
Preconditions The webpage that allows user to update information of a department is displayed
Steps 1. Provide department’s name in the name textbox or/and
2. Provide department’s location in the location textbox or/and
3. Provide department’s dean in the dean textbox or/and
4. Provide faculty information that the department has or/and
5. Provide department description in the description text area or/and
6. Click on add button
Expected results 1. The department is updated in the system
2. The summary of department has been updated 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
Requirement All fields are filled with data
Preconditions The webpage that allows user to update information of a department is displayed
1. Provide department’s name (which already exist in the system) in the name
Steps
textbox or/and
2. Provide department’s location in the location textbox or/and
3. Provide department’s dean in the dean textbox or/and
35

36. Testing Plan Document
4. Provide faculty information that the department has or/and
5. Provide department description in the description text area or/and
6. Click on add button
Expected results 1. The department is NOT updated in the system
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
Requirement NOT all fields are filled with data
Preconditions The webpage that allows user to update information of a department is displayed
Steps 1. Provide empty department’s name in the name textbox or/and
2. Provide empty department’s location in the location textbox or/and
3. Provide empty department’s dean in the dean textbox or/and
4. Provide empty faculty information that the department has or/and
5. Provide department description in the description text area or/and
6. Click on add button
Expected results 1. The department is NOT updated in the system
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

37. Testing Plan Document
3.8 Fail to update a department when inputting special character(s) to one
or some or all fields
Test case: Fail to update a department when inputting special character(s) to one or
Name
some or all fields
Requirement All fields are filled with data
Preconditions The webpage that allows user to update information of a department is displayed
1. Provide department’s name containing special character(s) in the name
Steps
textbox or/and
2. Provide department’s location containing special character(s) in the location
textbox or/and
3. Provide department’s dean containing special character(s) in the dean
textbox or/and
4. Provide faculty information containing special character(s) or/and
5. Provide department description containing special character(s) in the
description text area or/and
6. Click on add button
Expected results 1. The department is NOT updated in the system
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)”
3.9 Update cancel
Name Test case: Update cancel
When user decides to cancel updating, the system must allow him/her to stop the
Requirement
operation
Preconditions The webpage that allows user to update information of a department is displayed
Steps Click on add button
37

38. Testing Plan Document
Expected results The department is NOT updated in the system
User is redirected to his/her main page
3.10 Delete a department
Name Test case: Delete a department
When user decides to delete the selected department, the system removes that
Requirement
department from the system
Preconditions The webpage that allows user to delete information of a department is displayed
Steps 1. User chooses a department to delete from a drop down list.
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.
3. User confirms to delete the selected department by clicking on delete
button.
Expected results The system deletes the selected department from the system
3.11 Delete cancel
Name Test case: Delete cancel
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
Steps 1. User chooses a department to delete from a drop down list.
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.
3. User click on cancel button.
Expected results The selected department is NOT deleted from the system
User is redirected to his/her main page
38

39. Testing Plan Document
4. Test Cases of Manage Lecturer Information use case
4.1 Add a lecturer with valid information successfully
Name Test case: Add a lecturer with valid information successfully
Requirement All fields are filled with valid data
Preconditions The webpage that allows user to input information of a lecturer is displayed
Steps 1. Provide lecturer’s name in the name textbox
2. Choose lecturer’s date of birth in the calendar
3. Provide lecturer’s cell-phone number in the cell-phone textbox
4. Provide lecturer’s email address in the email textbox
5. Provide lecturer’s department where that lecturer belongs in the
department textbox
6. Provide lecturer’s degree in the degree textbox
7. Click on add button
Expected results 1. The lecturer is added to the system
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
Requirement NOT all fields are filled with data
Preconditions The webpage that allows user to input information of a department is displayed
Steps 1. Provide empty lecturer’s name in the name textbox or/and
2. Choose empty lecturer’s date of birth in the calendar or/and
3. Provide empty lecturer’s cell-phone number in the cell-phone textbox or/and
39

40. Testing Plan Document
4. Provide empty lecturer’s email address in the email textbox or/and
5. Provide empty lecturer’s department where that lecturer belongs in the
department textbox or/and
6. Provide empty lecturer’s degree in the degree textbox or/and
7. Click on add button
Expected results 1. The lecturer is NOT added to the system
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
Test case: Fail to add a lecturer when inputting special character(s) to one or some or
Name
all fields
Requirement All fields are filled with data
Preconditions The webpage that allows user to input information of a lecturer is displayed
1. Provide lecturer’s name containing special character(s) the name textbox
Steps
or/and
2. Choose lecturer’s date of birth in the calendar or/and
3. Provide lecturer’s cell-phone number containing special character(s) in the
cell-phone textbox or/and
4. Provide lecturer’s email address containing special character(s) in the email
textbox or/and
5. Provide lecturer’s department where that lecturer belongs, containing
special character(s), in the department textbox or/and
6. Provide lecturer’s degree containing special character(s) in the degree
textbox or/and
7. Click on add button
Expected results 1. The lecturer is NOT added to the system
2. The user is redirected to the error page with a warning “Fail to add the lecturer to
40

41. Testing Plan Document
the system. Some fields contains special character(s)”
4.4 Look for a lecturer
Name Test case: Look for a lecturer
When user wants to update or delete a lecturer, he/she has to look for information
Requirement
of the lecturer he/she wants to delete or modify information.
The webpage that allows user to look for information of a lecturer is displayed. It can
Preconditions
be update or delete page.
Steps 1. User chooses the department where the lecturer belongs
2. Verify that the system retrieves and displays the list of lecturers of that
department
3. User choose a lecturer from the list
4. Verify that the summary of information of selected lecturer is displayed
Expected results 1. Information of the select lecturer is displayed
4.5 Update a lecturer with valid information successfully
Name Test case: Update a lecturer with valid information successfully
Requirement All fields are filled with valid data
The webpage that allows user to update information of a lecturer is displayed. (To be
Preconditions
noted that we have test case for looking for lecturer above already. There’s no need
to repeat it here.)
Steps 1. Provide lecturer’s name in the name textbox or/and
2. Choose lecturer’s date of birth in the calendar or/and
3. Provide lecturer’s cell-phone number in the cell-phone textbox or/and
4. Provide lecturer’s email address in the email textbox or/and
5. Provide lecturer’s department where that lecturer belongs in the
department textbox or/and
6. Provide lecturer’s degree in the degree textbox or/and
7. Click on add button
41

42. Testing Plan Document
Expected results 1. The lecturer is updated in the system
2. The summary of the lecturer has been updated is displayed
42

43. 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
Requirement NOT all fields are filled with data
The webpage that allows user to update information of a lecturer is displayed.(To be
Preconditions
noted that we have test case for looking for lecturer above already. There’s no need
to repeat it here.)
Steps 1. Provide empty lecturer’s name in the name textbox or/and
2. Choose empty lecturer’s date of birth in the calendar or/and
3. Provide empty lecturer’s cell-phone number in the cell-phone textbox or/and
4. Provide empty lecturer’s email address in the email textbox or/and
5. Provide empty lecturer’s department where that lecturer belongs in the
department textbox or/and
6. Provide empty lecturer’s degree in the degree textbox or/and
7. Click on add button
Expected results 1. The lecturer is NOT updated in the system
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”
4.7 Fail to update a lecturer information when inputting special
character(s) to one or some or all fields
Test case: Fail to update a lecturer information when inputting special character(s) to
Name
one or some or all fields
Requirement All fields are filled with data
The webpage that allows user to update information of a lecturer is displayed. (To be
Preconditions
noted that we have test case for looking for lecturer above already. There’s no need
to repeat it here.)
43

44. Testing Plan Document
1. Provide empty lecturer’s name containing special character(s) in the name
Steps
textbox or/and
2. Choose empty lecturer’s date of birth in the calendar or/and
3. Provide empty lecturer’s cell-phone number containing special character(s)
in the cell-phone textbox or/and
4. Provide empty lecturer’s email address containing special character(s) in the
email textbox or/and
5. Provide empty lecturer’s department where that lecturer belongs, containing
special character(s) in the department textbox or/and
6. Provide empty lecturer’s degree containing special character(s) in the degree
textbox
7. Click on add button
Expected results 1. The lecturer is NOT updated in the system
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)”
4.8 Update cancel
Name Test case: Update cancel
When user decides to cancel updating, the system must allow him/her to stop the
Requirement
operation
The webpage that allows user to update information of a lecturer is displayed. (To be
Preconditions
noted that we have test case for looking for lecturer above already. There’s no need
to repeat it here.)
Steps Click on cancel button
Expected results The lecturer is NOT updated in the system
User is redirected to his/her main page
4.9 Delete a lecturer
Name Test case: Delete a lecturer
44

45. Testing Plan Document
When user decides to delete the selected lecturer, the system removes that lecturer
Requirement
from the system
The webpage that allows user to delete information of a lecturer is displayed. (To be
Preconditions
noted that we have test case for looking for lecturer above already. There’s no need
to repeat it here.)
Steps Click on delete button
Expected results The system deletes the selected lecturer from the system
User is redirected to his/her main page
4.10 Delete cancel
Name Test case: Delete cancel
Requirement When user decides to cancel deletion, the system allows user to cancel the operation
The webpage that allows user to delete information of a lecturer is displayed. (To be
Preconditions
noted that we have test case for looking for lecturer above already. There’s no need
to repeat it here.)
Steps Click on cancel button
Expected results The selected lecturer is NOT deleted from the system
User is redirected to his/her main page
45

46. Testing Plan Document
5. Test Cases of Manage Student Information Use Case
5.1 Add a student with valid information successfully
Name Test case: Add a student with valid information successfully
Requirement All fields are filled with valid data
Preconditions The webpage that allows user to input information of a student is displayed
Steps 1. Provide student’s name in the name textbox
2. Provide student’s ID in the name textbox
3. Choose student’s faculty in the list of faculty
4. Choose student’s academic duration in the range list
5. Choose student’s academic year in the list
6. Choose semester of this academic year.
7. Choose course of this semester.
8. Click on add button
Expected results 1. The student is added to the system
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
Requirement NOT all fields are filled with data
Preconditions The webpage that allows user to input information of a student is displayed
Steps 1. Provide empty student’s name in the name textbox or/and
2. Provide empty student’s ID in the name textbox or/and
3. Choose empty student’s faculty in the list of faculty or/and
46

47. Testing Plan Document
4. Choose empty student’s academic duration in the range list or/and
5. Choose empty student’s academic year in the list or/and
6. Choose empty semester of this academic year or/and
7. Choose empty course of this semester or/and
8. Click on add button
Expected results 1. The student is NOT added to the system
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
Test case: Fail to add a student when inputting special character(s) to one or some or
Name
all fields
Requirement All fields are filled with data
Preconditions The webpage that allows user to input information of a lecturer is displayed
1. Provide student’s name containing special character(s) the name textbox
Steps
or/and
2. Provide student’s ID containing special character(s) in the name textbox
or/and
3. Choose student’s faculty in the list of faculty or/and
4. Choose student’s academic duration in the range list or/and
5. Choose student’s academic year in the list or/and
6. Choose semester of this academic year or/and
7. Choose course of this semester or/and
8. Click on add button
Expected results 1. The student is NOT added to the system
2. The user is redirected to the error page with a warning “Fail to add the student to
47

48. Testing Plan Document
the system. Some fields contains special character(s)”
5.4 Search student by student ID or/and by student name
Name Test case: Search student by student ID or/and by student name
User wants to find information of a specific student with student’s ID or list of
Requirement
students with given name.
Preconditions The webpage allows user to find students is displayed
Steps 1. Chooses ID and Name filter from the filter drop down list
2. Provide an ID in the ID textbox or/and
3. Provide a name in the name textbox
4. Click on search button
The information of student with given ID or a list of student(s) with given name is
Expected results
displayed
5.5 Fail to search student by student ID or/and by student name when
providing invalid student ID or/and student name
Test case: Fail to search student by student ID or/and by student name when
Name
providing invalid student ID or/and student name
User wants to find information of student whose ID or/and name does not exist in
Requirement
the system, then the system must notify the user about this
Preconditions The webpage allows user to find students is displayed
Steps 1. Chooses ID and Name filter from the filter drop down list
2. Provide an invalid ID in the ID textbox or/and
3. Provide a invalid name in the name textbox
4. Click on search button
The user is redirected to the error page with a warning “The desired student is not
Expected results
found”
48

49. Testing Plan Document
5.6 Fail to search student by student ID or/and by student name when
providing empty student ID or/and student name
Test case: Fail to search student by student ID or/and by student name when
Name
providing empty student ID or/and student name
User wants to find information of a specific student’s ID or list of students with given
Requirement
name.
Preconditions The webpage allows user to find students is displayed
Steps 1. Chooses ID and Name filter from the filter drop down list
2. Provide an empty ID in the ID textbox or/and
3. Provide a empty name in the name textbox
4. Click on search button
The user is redirected to the error page with a warning “You must provide an ID
Expected results
or/and student name”
5.7 Search student by student ID or/and by student name
Name Test case: Search student by student ID or/and by student name
User wants to view tuition fee information of students of a specific faculty with a
Requirement
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
2. Choose a faculty from the drop down list
3. Choose a academic duration from drop down list
4. Click on search button
49

50. Testing Plan Document
Expected results The information of students of selected faculty with specific academic duration
50

51. Testing Plan Document
5.8 Search student by academic year, semester, and course
Name Test case: Search student by academic year, semester, and course
User wants to find information of students in a specific academic year and/or
Requirement
semester and/or course
Preconditions The webpage allows user to find students is displayed
1. Chooses academic year, semester, and course filter from the filter drop
Steps
down list
2. Choose a academic year from the academic year drop down list or/and
3. Choose a semester from the semester drop down list or/and
4. Choose a course from the course drop down list
5. Click on search button
The information of students of selected academic year and/or semester and/or
Expected results
course is displayed
5.9 Update a student with valid information successfully
Name Test case: Update a student with valid information successfully
Requirement All fields are filled with valid data
The webpage that allows user to update information of a student is displayed. (To be
Preconditions
noted that we have test cases searching for student above already. There’s no need
to repeat it here)
Steps 1. Provide student’s name in the name textbox or/and
2. Provide student’s ID in the name textbox or/and
3. Choose student’s faculty in the list of faculty or/and
4. Choose student’s academic duration in the range list or/and
5. Choose student’s academic year in the list or/and
6. Choose semester of this academic year or/and
7. Choose course of this semester or/and
51

52. Testing Plan Document
8. Click on update button
Expected results 1. The student is updated in the system
2. The summary of the student has been updated is displayed
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
Requirement NOT all fields are filled with data
The webpage that allows user to update information of a student is displayed (To be
Preconditions
noted that we have test cases searching for student above already. There’s no need
to repeat it here)
Steps 1. Provide empty student’s name in the name textbox or/and
2. Provide empty student’s ID in the name textbox or/and
3. Choose student’s faculty in the list of faculty or/and
4. Choose student’s academic duration in the range list or/and
5. Choose student’s academic year in the list or/and
6. Choose semester of this academic year or/and
7. Choose course of this semester or/and
8. Click on update button
Expected results 1. The student is NOT updated in the system
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”
5.11 Fail to update a student information when inputting special character(s)
to one or some or all fields
Test case: Fail to update a student information when inputting special character(s) to
Name
one or some or all fields
52

53. Testing Plan Document
Requirement All fields are filled with data
The webpage that allows user to update information of a student is displayed. (To be
Preconditions
noted that we have test cases searching for student above already. There’s no need
to repeat it here)
Steps 1. Provide empty student’s name in the name textbox or/and
2. Provide empty student’s ID in the name textbox or/and
3. Choose student’s faculty in the list of faculty or/and
4. Choose student’s academic duration in the range list or/and
5. Choose student’s academic year in the list or/and
6. Choose semester of this academic year or/and
7. Choose course of this semester or/and
8. Click on update button
Expected results 1. The student is NOT updated in the system
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)”
5.12 Update is canceled
Name Test case: Update is canceled
When user decides to cancel updating, the system must allow him/her to stop the
Requirement
operation
The webpage that allows user to update information of a student is displayed. (To be
Preconditions
noted that we have test cases searching for student above already. There’s no need
to repeat it here.)
Steps Click on cancel button
Expected results The student is NOT updated in the system
User is redirected to his/her main pages
53