Test plan for online movie ticketing system

Test report for online movie ticketing system developed by ILSE Inc, written by Luo linbo

1. The objective of testing effort and intended audiences

The objective is to to determine if the software satisfies the business requirements. Besides that, it will identify invalid states and values in the system. After integration of various modules, system integrity will be stressed-tested of its stability. The intended audiences are our clients and our supervisor Mr. Kevin Anthony Jones.

2. Testing strategy

both verification and validation test
constructive test
testing accomplished by independent test group
testing conducted independent of debugging
test scope: unit testing and block testing (due to the limitation of time)

3. Software product overview

The aim of the project is to implement a new online movie ticketing system that enable:

client to book movie online
client to cancel movie booked
client to view information of movie available
client to choose their own seating
administrator and user to access the same database through online interface
administrator to organize movie information online

The advantages of this new system are:

database system is integrated as part of the online system
online database does not need to be duplicated for offline database
clients can pay and book movie through electronics transaction
clients have flexibility in choosing the seating they like
administrator can update online (system) database at real time

3. Test scope and Test plan

Our testing team will only conduct the unit testing and block testing due to the limitation of time.

For unit test, we will employ both static and dynamic testing techniques. Our basic component is the .java and .jsp file. Since the inspection and compilation has already been done by programmer, we will only do the walkthrough for static testing. After that, we will do the white-box testing. The test cases will be derived from basis paths. So they will not be depicted here. Our test completion criteria is the basic function of the module and satisfaction for the requirement.

Forthe high level testing, we divide our program into two major block-customer interface and administrator interface. Instead of the focus on technique aspects, our main concern is the micro-behavior of each block. The black box testing will be employed here. We will use equivalence partitioning, boundary value and logic-based testing techniques for Test Data Selection.

4. Outline of testing process

Pre-requisite: The programmer has completed the unit testing by inspection and compilation.

5. Testing environment

5.1 Hardware

The system is hardware-independent

5.2 Operating system

Windows 2000
Windows XP

5.3 Required software

Java SDK 1.2
Apache Tomcat 1.4.3
Brower: Microsoft explorer 5 and above, Mozart, Netscape 6 and above
Microsoft Access 97 or later
Java ODBC driver

6. Roles and responsibilities

6.1 Test team

Test Controller: Luo Linbo

Test Engineer : Hartono Kasman & Choong Hon Ye

6.2 Test support team

Support programmer: Tan Chiew Hua & Yeo Tze Choog

7. Testing phases and cycles

7.1 Validation testing cycle

7.1.1 The system requirement validation

Testing procedure:

The refined client requirement is carefully studied.
Appropriate objects with services and attributes are studied and mapped to the class diagram produced by designers.
Every service in classes is matched with corresponding functions required in the system.

Sample Test case:

Client’s requirement 1: “The user logs in by giving his credit card ID and his password. He selects whether he wants to book some his tickets or cancel his tickets which he had booked earlier. If he wants to cancel then it’s possible only if two or more hours are left for the movie. The system has to validate all this.”

Client objects	Designer objects
Credit card ID	Credit_Card (Database)
Password	Password (Database)
Tickets	NA

Client services	Designer services
Login	NA
Book	forward (Booking)
Cancel	forward (Cancel)
Validate	forward (Validate)

7.1.2 The implementation validation

Testing procedure:

The syntaxes of functions implemented are compared to the functionality documentation in the class diagram.
The relationship of among objects is compared to the relationship among classes in the class diagram. e.g.. Multiplicity, associative and aggregation relation.
The work flow of the system implemented is matched with the working sequence provided by the client.

7.2 Verification testing cycle

7.2.1 Unit testing

We adopt white box testing in this stage. This testing was carried out on individual which is the .java file that programmer have designed.

(a) static testing

we did the walkthrough of the whole program. All the names of the variables are scrutinized to make sure that they are truly reflective of the element they represent. Some syntax errors and logic errors were captured in this phase.

(b) Dynamic testing

Component was checked and the flow graph wad constructed from the analysis. The test cases was derived from the path path.

Basis Path testing for Admins package:

Method	Flow graph & test cases	V(G)	Basis Path
Movieedit(String)	Click Here	6	Path 1: 1-2-3-5-6-7-8-9-10-11-12-13-14-15 Path 2: 1-2-3-1-2-3-5-6-7-8-10-11-12-13-14-15 Path 3: 1-2-3-5-6-7-8-6-7-8-10-11-12-13-14-15 Path 4: 1-2-3-1-2-3-5-6-7-8-6-7-8-10-11-12-13-11-12-13-14 Path 5: 1-2-4-5-6-7-8-10-11-12-13-14-15 Path 6: 1-2-4-5-6-7-9-10-11-12-13-14-15
Custdel(String)	Click Here	3	Path 1: 1-2-3... Path 2: 1-2-3-5-6 Path 3: 1-2-4-5-6

Basis Path testing for Customer package:

Method

Flow graph & test cases

V (G)

Basis Path

BookingRequest.

Process( )

Click Here

Path 1: 1-2-3...
Path 2: 1-2-4-5-6
Path 3: 1-5-6

CancelRequest

Process()

Click Here

Path 1: 1-2-3...
Path 2: 1-2-4-5-6
Path 3: 1-5-6

7.2.2 Block testing

Graph-Based Testing

Administrator Block:

Test Cases and Results:

Login module

Test Data Selection method: Equivalence Partitioning

Test Case

Purpose

Result

Expected Output? (Y/N)

User Name: java

Password : sun

Test if login module for administrator working

User Name: java

Password : 000000

Test if login module for administrator working

Add movie module

Test Data Selection method: Boundary Value Analysis (Note: only the input ticket price is tested using this method. The ticket price should be in the range 4 to 15)

Assumption: All the other necessary inputs are valid

Test Case	Purpose	Result	Expected Output?(Y/N)
Ticket price:$7 (valid input)	Check if the movie with normal price can be added	Movie was added successfully	Y
Ticket price:$4 (lower boundary)	Check if the movie with lower boundary price can be added	Movie was added successfully	Y
Ticket price:$15 (upper boundary)	Check if the movie with upper boundary price can be added	Movie was added successfully	Y
Ticket price:$3 (invalid input)	Check if the system will handle the invalid price which is lower than boundary	Movie was still added unconditionally	N
Ticket price:$20 (invalid input)	Check if the system will handle the invalid price which is higher than boundary	Movie was still added unconditionally	N
Ticket price: ABC (invalid input)	Check if the system will handle the invalid price which is not an numerical value	Movie was still added unconditionally	N

Edit movie properties module

Test Data Selection method: Equivalence Partitioning

Classes:

The time interval is 2 hours

The time interval is less than 2 hours

The time interval is greater than 2 hours

Assumption: All the other necessary inputs are valid

Test Case	Purpose	Result	Expected Output?(Y/N)
Start time:2.30 End time:4.30 (valid input)	Check if the movie with correctl duration can be edited	Movie was added edited	Y
Start time:2.30 End time:9.30 (invalid input)	Check if the movie with the duration higher than the correct one will generate error message	Movie was still edited wrongly	N
Start time:2.30 End time:3.30 (invalid input)	Check if the movie with the duration lowerr than the correct one will generate error message	Movie was still edited wrongly	N

Add customer, remove customer, and edit customer properties modules's test cases was derived similarly

Customer Block

Booking Movie Module

Test Data Selection method: Equivalence Partitioning

Assumption: All the other necessary inputs are valid

Test Case

Purpose

Result

Expected Output?(Y/N)

Name: Luo

Credit No:1111-1111-1111-1111

Check if the user with valid credit no can book the movie

Movie was added edited

Name: Luo

Credit No:0000-0000-0000-0000

Check if the user with invalid credit cannot book the movie

The data was reseted

Cancelling Movie Module

Test Data Selection method: Equivalence Partitioning

Assumption: All the other necessary inputs are valid

Test Case

Purpose

Result

Expected Output?(Y/N)

Name: Luo

Credit No:1111-1111-1111-1111

Check if the user with valid credit no can cancel the movie

Movie was cancelled edited

Name: Luo

Credit No:0000-0000-0000-0000

Check if the user with invalid credit cannot cancel the movie

The data was reseted

7. Testing tool sugggested for the future testing in the project

Rational TestManager Version 2002 is suggested to do the future testing. However, due to the limitation of time, we don't apply it in this stage. The reason for choosing this tool is that it is adapable to the change in the requirement. Rational TestManager provides the important ability to trace the impact of requirements and other changes by automatically flagging potentially impacted test cases. Such tool will ease the process of the testing, and even in the maintainence stage.

8. References

Pressman S. Roger., Software engineering: A practitioner's Approach, fifth edition McGraw-Hill 2001