testing plan test case

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

Upload: guest4c6fd6

Post on 17-May-2015

5.478 views

Category:

Technology


3 download

DESCRIPTION

Document

TRANSCRIPT

Testing Plan & Test case Document

12/7/2007

Ho Chi Minh National University – International University

Instructor: Phan Viet Hoang

Group 6

Team member Signature

Nguyen Duc Quan

Le Vu Hoang

Tran Minh Phung

Phan Duy Tan

Huynh Da Thuc

Date December 7th , 2007

Version 1.0

Status Baseline

Author Team TiHonMumMim

Reviewer Team TiHonMumMim

Documenter Nguyen Duc Quan

Testing Plan Document

2

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

Testing Plan Document

3

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

Testing Plan Document

4

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

Testing Plan Document

5

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

Testing Plan Document

6

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

Testing Plan Document

7

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.

Testing Plan Document

8

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.

Testing Plan Document

9

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.

Testing Plan Document

10

System architecture with sub-system model

System architecture with layer model

Testing Plan Document

11

Testing Plan Document

12

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

Testing Plan Document

13

(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.

Testing Plan Document

14

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.

Testing Plan Document

15

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.

Testing Plan Document

16

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.

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.

Processes should be invoked manually.

Small or minimally sized databases (limited number of records) should be

Testing Plan Document

17

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?

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:

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.

Special Considerations Access to the OURS Server and the existing Course Catalog System is

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 "background

load" on the system. The initial test should be performed with a "nominal" 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.

Testing Plan Document

18

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:

- 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).

Completion Criteria Single Transaction / single user: Successful completion of the test scripts

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.

Special Considerations: Comprehensive performance testing includes having a "background" load

on the server. There are several methods that can be used to perform this,

including:

"Drive transactions" directly to the server, usually in the form of MySQL

calls.

Create "virtual" 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 "traffic."

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

Testing Plan Document

19

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 "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 Verify System Response time for designated transactions or

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.

Completion Criteria Multiple transactions / multiple users: Successful completion of

the tests without any failures and within acceptable time

allocation.

Special Considerations Load testing should be performed on a dedicated machine or

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.

scaled equally.

Testing Plan Document

20

Test Objective Verify that the system and software function properly and

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.

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.

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

Testing Plan Document

21

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.

Test Objective Verify that the application / system successfully functions

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.

Completion Criteria All planned tests have been executed and specified system

limits are reached / exceeded without the software or software

failing.

Special Considerations What period of time would be considered an acceptable time

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

Testing Plan Document

22

7. Environmental Needs

7.1 Tools

Tool Version

Performance Testing AdventnetQEngin WebTest Last version

Project Management Microsoft Project

Microsoft Word

Microsoft Excel

Last version

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

Design tool Photoshop CS2

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

Testing Plan Document

23

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.

Milestone Task Start Date End Date

Iteration C1: Review 3

Test Planning

Test Design

Test Development

Test Execution

Test Evaluation

9th November 7th December

Iteration C2: Review 4

Test Planning

Test Design

Test Development

Test Execution

Test Evaluation

7th December 28th December

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:

Testing Plan Document

24

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

Testing Plan Document

25

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

Administrator

Ensures test environment and assets are managed and

maintained.

Responsibilities:

Administer test management system

Install / manage worker access to test systems

Database

Administration

Database Manager

Ensures test data (database) environment and assets are

managed and maintained.

Responsibilities:

Administer test data (database)

Designer Identifies and defines the operations, attributes, and

associations of the test classes

Responsibilities:

Testing Plan Document

26

Identifies and defines the test class(es)

Identifies and defines the test packages

Implementer Implements and unit tests the test classes and test

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

OURS Server Server for simulating the environment

of real OURS system

Course Catalog Database Simulated database

2 Remote PCs (with internet access) PCs for connecting to OURS via

internet

2 Local PCs (connected via LAN) Local network computers

Test Development PC's - 2

Load Simulator Simulator for load and performance

test

Testing Plan Document

27

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.

Testing Plan Document

28

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

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

Preconditions The user is at the homepage or the log in page

Testing Plan Document

29

Steps 1. Provide valid username in the username textbox

2. Provide invalid password in the password textbox

3. Click on log in button

Expected results The user is redirected to the error page with a warning “You have provided invalid

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

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

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

Expected results The user is redirected to the error page with a warning “You must provide both

username and password”

Testing Plan Document

30

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

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

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

Expected results User 2 is redirected to the error page with a warning “This account is being used by

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

Testing Plan Document

31

Steps 1. Provides username of given account being locked

2. Provide password of given account being locked

3. Click on log in button

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”

2.9 Recover the password

2.10 User choose the wrong security question or type the wrong answer

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

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

The password is reset to the default password “Abcd1234”

The system redirects the user to the log in page

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

Testing Plan Document

32

2.11 User input the empty answer for the security question

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

2. Specify the wrong answer of the security question in the text box

3. Click on the Recovery password button

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

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

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

Testing Plan Document

33

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

3.3 Fail to add a department when one or some or all fields are empty

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

Steps 1. Provide department’s name (which already exist in the system) in the name

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”

Name Test case: Fail to add a department when one or some or all fields are empty

Testing Plan Document

34

3.4 Fail to add a department when inputting special character(s) to one or

some or all fields

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”

Name Test case: Fail to add a department when inputting special character(s) to one or

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

Steps 1. Provide department’s name containing special character(s) in the name

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

Testing Plan Document

35

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

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)”

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

Steps 1. Provide department’s name (which already exist in the system) 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

Testing Plan Document

36

3.7 Fail to update a department when one or some or all fields are empty

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”

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”

Testing Plan Document

37

3.8 Fail to update a department when inputting special character(s) to one

or some or all fields

3.9 Update cancel

Name Test case: Fail to update a department when inputting special character(s) to one or

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

Steps 1. Provide department’s name containing special character(s) in the name

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)”

Name Test case: Update cancel

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

Steps Click on add button

Testing Plan Document

38

3.10 Delete a department

3.11 Delete cancel

Expected results The department is NOT updated in the system

User is redirected to his/her main page

Name Test case: Delete a department

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

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

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

Testing Plan Document

39

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

Testing Plan Document

40

4.3 Fail to add a lecturer when inputting special character(s) to one or some

or all fields

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”

Name Test case: Fail to add a lecturer when inputting special character(s) to one or some or

all fields

Requirement All fields are filled with data

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. 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

Testing Plan Document

41

4.4 Look for a lecturer

Name Test case: Look for a lecturer

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.

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

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.)

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

the system. Some fields contains special character(s)”

Testing Plan Document

42

Expected results 1. The lecturer is updated in the system

2. The summary of the lecturer has been updated is displayed

Testing Plan Document

43

4.6 Fail to update a lecturer when one or some or all fields are empty

4.7 Fail to update a lecturer information when inputting special

character(s) to one or some or all fields

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

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.)

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”

Name Test case: Fail to update a lecturer information when inputting special character(s) to

one or some or all fields

Requirement All fields are filled with data

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.)

Testing Plan Document

44

4.8 Update cancel

4.9 Delete a lecturer

Steps 1. Provide empty lecturer’s name containing special character(s) 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 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)”

Name Test case: Update cancel

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.)

Steps Click on cancel button

Expected results The lecturer is NOT updated in the system

User is redirected to his/her main page

Name Test case: Delete a lecturer

Testing Plan Document

45

4.10 Delete cancel

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.)

Steps Click on delete button

Expected results The system deletes the selected lecturer from the system

User is redirected to his/her main page

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 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.)

Steps Click on cancel button

Expected results The selected lecturer is NOT deleted from the system

User is redirected to his/her main page

Testing Plan Document

46

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

Testing Plan Document

47

5.3 Fail to add a student when inputting special character(s) to one or some

or all fields

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”

Name Test case: Fail to add a student when inputting special character(s) to one or some or

all fields

Requirement All fields are filled with data

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. 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

Testing Plan Document

48

5.4 Search student by student ID or/and by student name

5.5 Fail to search student by student ID or/and by student name when

providing invalid student ID or/and student name

the system. Some fields contains special character(s)”

Name Test case: Search student by student ID or/and by student name

Requirement User wants to find information of a specific student with student’s ID or list of

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

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

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

Expected results The user is redirected to the error page with a warning “The desired student is not

found”

Testing Plan Document

49

5.6 Fail to search student by student ID or/and by student name when

providing empty student ID or/and student name

5.7 Search student by student ID or/and by student name

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.

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

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: Search student by student ID or/and by 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

2. Choose a faculty from the drop down list

3. Choose a academic duration from drop down list

4. Click on search button

Testing Plan Document

50

Expected results The information of students of selected faculty with specific academic duration

Testing Plan Document

51

5.8 Search student by academic year, semester, and course

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

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)

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

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

Preconditions The webpage allows user to find 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

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

Expected results The information of students of selected academic year and/or semester and/or

course is displayed

Testing Plan Document

52

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

5.11 Fail to update a student information when inputting special character(s)

to one or some or all fields

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

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)

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”

Name Test case: Fail to update a student information when inputting special character(s) to

one or some or all fields

Testing Plan Document

53

5.12 Update is canceled

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)

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)”

Name Test case: Update is canceled

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.)

Steps Click on cancel button

Expected results The student is NOT updated in the system

User is redirected to his/her main pages

Testing Plan Document

54

5.13 Delete a student

5.14 Delete is canceled

Name Test case: 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.)

Steps Click on delete button

Expected results The system deletes the selected student from the system

User is redirected to his/her main page

Name Test case: Delete is canceled

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)

Steps Click on cancel button

Expected results The selected student is NOT deleted from the system

User is redirected to his/her main page

Testing Plan Document

55

6. Test Case of Manage Course Offering Use Case

6.1 The user create a new course offering

6.2 Update the list of course offering

Name Test case: The user create a new course offering

Requirement The new course offering is created and distributed to the students

Preconditions The user must log in as the Academic Affair Staff

Steps 1. Click on the button Manage Course Offering

2. Click on the button Create a list of course offering

3. Click on the drop down list to choose the desired faculty

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

7. Click on the OK button to confirm the operation

Expected results The new course offering is created

The system displayed the list of course offering that has been created

The system redirects to the Manage Course Offering page

Name Test case: Update the list of course offering

Requirement The list of course offering is updated

Preconditions The user must log in as the Academic Affair Staff

Steps 1. Click on the button Manage Course Offering

2. Click on the button Update list of course offering

Testing Plan Document

56

6.3 Cancel during the Add list of course offering operation

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

5. Change the lecturer for each course (if desired)

6. Click on the Update button

7. Click on the OK button to confirm the operation

Expected results The confirmation displayed

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

Requirement No list of course offering is created

Preconditions The user must log in as the Academic Affair Staff

Steps 1. Click on the button Manage Course Offering

2. Click on the button Create a list of course offering

3. Click on the drop down list to choose the desired faculty

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

7. Click on the Cancel button

Expected results The confirmation displayed

The system redirects to the Manage Course Offering page

Testing Plan Document

57

6.4 Cancel during the Update list of course offering operation

6.5 The user creates an empty list of course offering

Name Test case: Cancel during the Update list of course offering operation

Requirement The selected list of course offering is not updated

Preconditions The user must log in as the Academic Affair Staff

Steps 1. Click on the button Manage Course Offering

2. Click on the button Update list of course offering

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

5. Change the lecturer for each course (if desired)

6. Click on the Update button

7. Click on the Cancel button to confirm the operation

Expected results The confirmation displayed

The system redirects to the Manage Course Offering page

Name Test case: The user creates an empty list of course offering

Requirement No empty list is created

Preconditions The user must log in as the Academic Affair Staff

Steps 1. Click on the button Manage Course Offering

2. Click on the button Create a list of course offering

3. Click on the drop down list to choose the desired faculty

4. Don’t click any check box in order not to select any course

Testing Plan Document

58

6.6 Update list of course offering while there’s no list of course offering for

specific faculty

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

7. Click on the OK button to confirm the operation

Expected results The confirmation is displayed

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

Name Test case: Update list of course offering while there’s no list of course offering for

specific faculty

Requirement Empty list of course offering is displayed

Preconditions 1. The user must log in as the Academic Affair Staff

2. The selected faculty has no list of course offering

Steps 1. Click on the button Manage Course Offering

2. Click on the button Update list of course offering

3. Click on the drop down list to choose the desired faculty

Expected results 1. The system displayed the empty list

2. A warning is displayed “There’s no list of course offering in this faculty.

Cannot update”

Testing Plan Document

59

7. Test Case of Manage Financial Activities Use Case

7.1 View tuition fee by student ID or/and by student name

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: 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

2. Provide an ID in the ID textbox or/and

3. Provide a name in the name textbox

4. Click on search button

Expected results The tuition fee information of student with given ID or student(s) with given name is

displayed

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

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

Testing Plan Document

60

7.3 Fail to view tuition fee by student ID or/and by student name when

providing empty student ID or/and student name

7.4 View tuition fee by faculty or/and by academic duration

Expected results The user is redirected to the error page with a warning “The desired student is not

found”

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

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

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

2. Choose a faculty from the drop down list

3. Choose a academic duration from drop down list

4. Click on search button

Testing Plan Document

61

7.5 View tuition fee by academic year, semester, and course

7.6 Update tuition fee status of a student

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

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

Expected results The tuition fee information of students of selected academic year and/or semester

and/or course is displayed

Name Test case: Update tuition fee status of a student

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.

Steps 1. Choose a student from the list

2. Change status of tuition fee of that student by choose tuition fee status from

Testing Plan Document

62

8. Test Case of View Academic History Use Case

Name Test case: Verify View Academic History

Requirement FR- 8 Grade management policy, UC - View Academic History

Preconditions The testing plan document is loaded.

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.

3. One filter is chosen.

4. Click View button.

Expected results Result:

The system displays a list of courses that match the filter.

Academic history of a student is display.

Verify that all these information match with FR-8 information.

8.1 Views all course have taken history.

the stats drop down list

3. Click on submit button

Expected results Tuition fee status of selected student is changed and the system notify the user.

Name Test case: View all courses have taken history

Requirement Student wants to view all courses information.

Preconditions The webpage allows student to view academic history

Testing Plan Document

63

8.2 View by specific year and semester.

8.3 View by passed and failed status.

9. Test Case of Register Course Use Case

9.1 User register more than 30 credits

Steps 1. Choose “All” filter from drop down list.

2. Click on “View” button

Expected results The information of all courses he/she has taken is displayed.

Name Test case: View by specific year and semester

Requirement Student wants to view all courses information of specific year or/and semester.

Preconditions The webpage allows student to view academic history.

Steps 1. Choose “Specific year and Semester” filter from drop down list.

2. Click on “View” button

Expected results The information of all courses he/she has taken is displayed.

Name Test case: View by specific year and semester

Requirement Student wants to view all courses information of passed and failed status.

Preconditions The webpage allows student to view academic history

Steps 1. Choose “passed and failed status” filter from drop down list.

2. Click on “View” button

Expected results The information of all courses he/she has taken is displayed.

Name Test case: User register more than 30 credits

Testing Plan Document

64

9.2 User selects less than 15 credits

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

Student can register maximum 30 credits and minimum 15 credits

Preconditions The testing plan document is loaded.

Steps 1. Click register course offering button

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

4. Click on the Register button

Expected results The system prompts the message “You cannot register more than 30 credits”

The system redirects to Register page

Name Test case: User selects less than 15 credits

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

Student can register maximum 30 credits and minimum 15 credits

Preconditions The testing plan document is loaded.

Steps 1. Click register course offering button

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

Testing Plan Document

65

9.3 Confirm registration of course offering.

Name Test case: Confirm registration of course offering.

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

Student can register maximum 30 credits and minimum 15 credits

Preconditions The testing plan document is loaded.

Steps 1. Click register course offering button.

2. Don’t register course offering yet.

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.

4. Click the submit button

Expected results The schedule is saved in the system.

List of course offering will be shown on the schedule of this student.

Verify that all these information match with FR-5 information.

4. Click on the Register button

Expected results The system prompts the message “You cannot register less than 15 credits”

The system redirects to Register page

Testing Plan Document

66

9.4 Confirm updating course offering.

Name Test case: Confirm updating course offering.

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

Student can register maximum 30 credits and minimum 15 credits

Preconditions The testing plan document is loaded.

Steps 1. Click register course offering button.

2. Click the update button schedule.

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.

5. Click the Update button

Expected

results

The schedule is saved in the system.

List of course offering is updated.

Verify that all these information match with FR-5 information.

C- Appendix

Message

ID Type Context Error Messages Actions

MS001 Info Authentication Failed Wrong password or username cannot

be found. OK

Testing Plan Document

67

MS002 Info Account locked Account locked. Please wait for 30

minutes or contact the administrator. OK

MS003 Info Account being used This account is being used by another

user. OK

MS004 Question Delete a department Are you sure you want to delete the

selected department? OK – Cancel

MS005 Question Update a lecturer Are you sure you want to update the

current displayed lecturer? OK – Cancel

MS006 Question Delete a lecturer Are you sure you want to delete the

selected lecturer? OK – Cancel

MS007 Question Update a student Are you sure you want to update the

modified student? OK – Cancel

MS008 Question Delete a student Are you sure you want to delete the

selected student? OK – Cancel

MS009 Info Student not found The selected student does not exist OK

MS010 Info No list of course

offering

This faculty has no list of course

offering yet Ok

MS011 Question Update tuition fee

status

Are you sure you want to update

tuition fee status of current student? OK – Cancel

MS012 Info Student not found Cannot find the result. OK

MS013 Info Course Registration

Closed

The course registration has been

closed OK

MS014 Info Register more than 30 You cannot register more than 30 OK

Testing Plan Document

68

credits credits

MS015 Info Register less than 15

credits

You cannot register less than 15

credits OK

MS016 Question Submit a schedule Are you sure you want to submit this

schedule? OK – Cancel

MS017 Question Reset changes to a

schedule

Are you sure you undo all the

changes you have made? OK – Cancel

D- Inspection Checklist

1. The following checklist items apply to the test plan. Completeness

Does the document meet all established templates and standards?

Is the document complete?

Are there any requirements that are not tested?

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?

Can every test described in the test plan be reasonably conducted?

Environment

Is the description of the environment complete?

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?

Can the performance tests be traced back to requirements in the specification?

Acceptance Criteria

Do the acceptance criteria match the standards of the organization?

Testing Plan Document

69

2. The following checklist items apply to the test cases: Clarity

Does each test case have a clear flow of events?

Does each test case test only one specific interaction?

Does each test case describe the interaction using specific user interface and data elements?

Is each test case repeatable by someone uninitiated on the project?

Completeness

Is every requirement in the SRS verified fully with individual test cases?

Are all of the steps in each test case necessary?

Are there any steps that are missing?

Are all alternative paths and exceptions accounted for?

Accuracy

For every action, is there an expected result?

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

Is each test case uniquely identified with a name and a number?

Can each test case be traced back to a specific requirement?