Testing Specifications

for

Airline Reservation Services

Web-Based Design
Version 1.4 approved

Prepared by Carlos Osorio

Traveling.com

February 11, 2012

Table of Contents
1.

Introduction.......................................................................................................... 4
1.1 System Scope.................................................................................................... 4

2.

Testing Requirements........................................................................................... 5
2.1 Assessment of Capabilities................................................................................ 5
2.2 Staff Competency.............................................................................................. 6
2.3 User Satisfaction............................................................................................... 7

3.

4.

The importance of unit/usability/system test planning process...........................8

3.1

Characteristics of test plans...........................................................................8

3.2

Test planning approach.................................................................................. 9

3.3

Approach taken for travelling.com test project............................................10

Outline of the test plan...................................................................................... 11

4.1 Scope.............................................................................................................. 11
4.2 System description and operation...................................................................11
4.3 Test Identification and test levels....................................................................12
4.3.1 Unit Testing............................................................................................... 12
4.3.2 Interface and Integration Testing..............................................................12
4.3.3 System Testing.......................................................................................... 12
4.3.4 Acceptance Testing................................................................................... 12
4.4 Planned tests and test schedules....................................................................13
4.4.1 Requirement-Based Testing.......................................................................13
4.4.2 Scenario Testing........................................................................................ 13
4.4.3 Performance Testing.................................................................................. 13
4.4.4 Alpha Testing............................................................................................. 14
4.4.5 Beta Testing.............................................................................................. 14
4.5 Requirement Traceability.................................................................................14
4.6 Test Method and Procedures............................................................................14

5.

Regression Testing.............................................................................................. 17
5.1 Introduction..................................................................................................... 17
5.2 Purpose........................................................................................................... 17
5.3 Components Being Tested...............................................................................17
5.4 Regression Testing requirements.....................................................................19

5.5 Test Strategy................................................................................................... 24

Test ID 21........................................................................................................... 24
Test ID 22........................................................................................................... 25
Test ID 23........................................................................................................... 26
Test ID 24........................................................................................................... 27
Test ID 25........................................................................................................... 28
5.6 Test Schedule.................................................................................................. 29
6.

Compatibility...................................................................................................... 30
6.1

Hardware Compatibility...............................................................................30

6.2

Software Compatibility................................................................................. 30

6.3

Network Compatibility.................................................................................30

7.

Summary............................................................................................................ 31

8.

Reference Material............................................................................................. 32

Appendix A............................................................................................................... 34

Revision History
Name

Date

Reason For Changes

Version

Carlos Osorio

1/15/2012

Assessing capabilities, competency and user

satisfaction. (RTM included)

1.0

Carlos Osorio

1/23/2012

Complete outline and table of contents

1.1

Carlos Osorio

1/29/2012

Test Methods/Procedures

1.2

Carlos Osorio

02/04/2012

Regression Testing

1.3

Carlos Osorio

02/11/2012

Final Review

1.4

1. Introduction
1.1 System Scope
The key project to be tested as a part of the software development cycle is a web
application which will allow customers to locate airplane tickets at the lowest possible price
when given the system a range of possible dates or a specific date to travel, a departure and a
destination. As an introduction for this project I have been asked to present an assessment of
capabilities, staff competency, user satisfaction, the approach that should be taken to obtain an
environment supportive of software testing and to identify the unpopulated matrix for your
requirements traceability matrix (RTM).

2. Testing Requirements
2.1 Assessment of Capabilities
In this step we are called to assess the capabilities of the companys pre-existent test
processes. This assessment can be divided into seven sub-procedures which are as follows:
Prepare for software testing projects: This category will help us identify what testing
approach should be used and when to perform such tests. This could include the identification of
approaches such as unit, component, integration and user testing.
Conduct test planning: Many development negative issues could be avoided with effective
development planning; with this in mind, to create a plan that depicts how the testing efforts are
going to be implemented should keep the testing as organized and effective as possible.
Executing the plan: As its name implies, to execute the plan puts action to the preparation and
planning already identified by the first two items. It might include requirements, design and
construction testing. (Perry, 2006)
Acceptance testing: This refers to the client accepting the software as the solution for their
problem and that the system has fulfilled all the requirements as well as the design specifications.
Test results analysis: Without an analysis of the results of the test, we might as well not test at
all. It is imperative that the data obtained from the tests is analyzed in order to proceed with the
correction of the possible issues discovered or any other predefined action.
Installation testing: Installation is the first interaction that exists between the end user and the
software thus the need to identify the possible ways of installing it (cloud, cd, etc.), platforms
supported, system requirements, incorrect installation due to firewalls, concurrent downloads,
etc. (Ramdeo, 2011)
Post-test analysis: This test is more effective when is performed in an on-going basis after each
test portion has been successfully performed. It might involve not only testers but developers,
users and Quality Assurance personnel.

2.2 Staff Competency

This practice should allow you to identify the competencies of your staff towards the
requirements to obtain CSTE certification (Certified Software Tester). The skills needed to
obtain the certificate are as follows:

Testing Principles
Build Test Environment
Test Planning
Managing Test Projects
Executing the Plan

Analysis and Reporting

Acceptance Testing
Test Outsourcing
Test Control and Security
Test New Technologies


It is also important to know that in order to obtain the CSTE certification you also need the
education and experience requirements.

A 4 year degree from accredited college-level institution & 2 years of experience in the

information services field, or

A 3 year degree from accredited college-level institution & 3 years of experience in the

information services field, or

A 2 year degree from accredited college-level institution & 4 years of experience in the

information services field, or

Six years of experience in the information services field

And

To be working, or have worked at any time within the prior 18 months, in the field

within covered by the certification designation. (softwarecertifications.org, 2011)

Travelling.com testing will be performed by CSTE certified personnel even

though the client should note that not all the developing team needs to be certified. Portions of
the developing effort do not need to be directly tested by its own developer thus the need to have
certain employees in charge of the testing of the project.

2.3 User Satisfaction

Usability testing is one of the tools used to achieve user satisfaction. This

approach is intended to identify is the proposed solution is performed as expected in an effective

and efficient manner. Usability testing is usually performed at various stages of the development
process to ensure that all usability requirements are being met in very step. (admin, 2011) This
type of testing can be related to the aforementioned testing techniques such as unit, component,
integrations and user testing.

Each portion of the system can be tested using these partial checks to check for

functionality and requirement problems that might arise when they are still small; this in the case
of unit testing that later becomes module testing. All the modules can be integrated and checked

for correct performance until we are able to obtain a fully working system in which alpha and
beta testing is feasible.

3. The importance of unit/usability/system test planning

process

The main purpose of software testing is to ensure that the system being delivered to the
client is bug free, performance efficient and requirement compliant. Software testing is a process
that must be embedded as part of the development stages in order to produce a cost efficient
method for testing instead of waiting until the development is completed.
Unit testing refers to tests performed in small units of code which are usually classes.
Once the unit or several units have passed the test, integration testing follows it. Integration
testing ensures that the interaction between units of the system is working properly. Usability
testing is the technique applied to evaluate that the system is working as intended.
Usability tests for system requirements, usability issues (error rates, timely response,
etc.), collects quantitative data on the performance and determines the user overall impression
and satisfaction with the products. Usability tests allow the design and development teams to
identify issues before they get coded.
These tests are usually implemented early in the development stages and as often as

possible. (usability.gov, n.d.) To plan the test strategy to be used is as important as performing
the tests. Poor system test planning process can be a burdensome and expensive practice.

3.1 Characteristics of test plans

In order to create an effective plan there are several items that must be considered and
they can fall into the following categories; requirement traceability, estimating, scheduling,
staffing, approach and test check procedures.

Requirements/Traceability: This step defines the system requirements and test that will
be conducted to validate them.

Estimating: This step refers to the resources that are expected to be used to accomplish
the tests.

Scheduling: It describes the milestones that should be reached in the different stages of
the testing process.

Staffing: It refers to the amount of qualified personal needed to accomplish the test plan
objectives.

Approach: This step answers the question, how is it going to be done? Here you will find
the methods, tools, techniques and strategies to be used.

Test Check Procedures: These are the procedures that are based on the design and test
plan to incorporate test cases and their correct and complete performance. (Duvvur, 2009)

3.2 Test planning approach

There are many types of tests that can be performed in order to ensure that the proposed
system is behaving as expected. Some of the types of testing are: functional, stress, load, ad-hoc,
usability, recovery, volume, integration, unit, module, regression, alpha, beta, amongst others.
(Parekh, n.d.) The questions that arise when doing testing are, under what circumstances should
certain tests be performed and when to perform them. There are two testing strategies that will
help us make those decisions.

White Box Testing

This type of testing is performed with knowledge of the internal code and uses

three types of testing; unit, integration and regression. Unit testing refers to tests performed in
small units of code which are usually classes. Once the unit or several units have passed the test
integration testing follows it. Integration testing ensures that the interaction between units of the
system is working properly. Regression testing verifies that any change or implementation

applied to the system has not disrupted the normal or expected operations of the system as a
whole.

As you can see white box testing checks the system from its roots (unit testing)

and works its way up to integrate the units and finally ensure that new capabilities do not affect
the whole system. The goal of white box testing is to test statements, decision points and
branches with the knowledge of the code that is making those paths possible and their possible
outcomes and scenarios. (Heckman, 2008)

Black Box Testing

As its name implies black box testing is performed with a black box on top the

code; in other words no coding or knowledge of the code is necessary to perform this testing
strategy. The main purpose of black box testing is to check the intended functionality of the
system, performance, scalability and usability. This type of testing requires that the tester has
thorough knowledge of the system requirements, its behavior and the possible case scenarios.
(Parekh, n.d.) (Repurposed from Software Testing Discussion Board 2, Professor Okoro)

3.3 Approach taken for travelling.com test project

In order to provide travelling.com with an expedited cost effective solution that will test
all the aspects of the proposed system, a combination of white box and black box testing
strategies will be implemented. The units of the system will be tested for correct functionality
before integrating into the different modules and regression testing will be in place to ensure that
the modules work before constructing larger portion of the system.
Once all the modules are integrated, the system will be tested for performance, scalability
and usability. Alpha testing will be performed by our team of developers and will focus on the
requirements and the performance required for the system. Travelling.com personal will be in
charge of performing beta testing once the alpha testing procedures have been finished. This will
allow us to fine tune any details of the look, usability or performance that were not identified in
the early stages of the development.

4. Outline of the test plan

4.1 Scope

The system has several requirements that are imperative for its correct operations

and best performance within its market. These requirements are presented in the Software
Design document already delivered to travelling.com. Test cases will be developed in order to
test for each requirement as well as performance testing.

4.2 System description and operation

Travelling.com is the main page that will allow users to perform flight/car rental

and hotel bookings from the system. The web application will have links to other pages such as
account, trips, news, FAQS and customer support. There are also landing pages that will be
accessed once a user has made a selection, i.e. flight search to flight itinerary to flight purchase.
In between flight itinerary and flight purchase there are more ramifications of possibilities for the
user; car rental/hotel booking.

These several combinations and scenarios will expand the number of test cases

and its possible outcomes. Flight search to flight itinerary to car rental to flight and car rental
purchasing; in the afore-mentioned scenario it is assumed that the user declined the possibility to
make a hotel reservation but decided to rent a car during his trip.

Tests will be performed in a test server that will have sample databases to mimic

the regular fluctuations of data of an airline database. There are three databases that will provide
data for the tests; airline, hotel and car rental databases. There is also an external service that
needs to be connected to the system via interface; the credit card processing application. The
service provider of this application will provide us with a secure testing site that has all the
capabilities and functionality of the real site without incurring into charges for any of the
payment methods applied while testing the system.

 4.3 Test Identification and test levels

There are four levels of software testing; unit, integration, system and acceptance.

Their definition and scope is as follows:

4.3.1 Unit Testing

Unit testing refers to the process of testing the smallest portions of the application,

also referred as units, in order to gain assurance that they are functioning properly. Unit testing
operations will be performed in all the units that compose the modules of the system.
(techtarget.com, 2007) For a list of the modules of the system please refer to section Appendix A
and the system RTM.

4.3.2 Interface and Integration Testing

The procedure tests the functionality of the different modules or components

when called to interact with other modules within the system. There are several modules
that require a working interface with external databases in order to meet requirements and
functionality. Tests will be performed not only for internal but the external interfaces
even though the system will not exercise direct control over such databases.

4.3.3 System Testing

This procedure brings together all units and interfaces and tests them as a group in

various ways. For the V&V plan of traveling.com we have chosen a combination of bottom up
tests procedures in which the units and interfaces will be tested first and work our way up the
higher end modules. Once tests have a positive outcome we will perform top down testing in
order to obtain double assurance that the product is performing as expected.

4.3.4 Acceptance Testing

This is the final test and it is performed by the client in order to determine that all

requirements and specifications have been met according to the contract. (Repurposed from

Software Design, Individual Project 5, Professor Brian Bertrand)

4.4 Planned tests and test schedules

Aside the already presented test levels that will be performed to the system in the

various development stages, there are additional tests that need be performed to ensure the
quality of the product to be delivered. Those tests are requirement, scenario, performance, alpha
and beta testing.

4.4.1 Requirement-Based Testing

The system has to perform certain functions that are essential to produce the

expected results. Traveling.com has specific requirements that must be implemented such as
users being able to perform flight searches and obtain a list of available flights. Tests will be
performed in order to guarantee that those requirements are being met.

4.4.2 Scenario Testing

Use case scenarios have been presented in section of this document and tests will

be performed with those scenarios in mind. Task feature testing will be performed in order to
test that presented use-case scenarios are functional together with forced error condition testing
to expose the system to intended errors in order to check the systems response.

4.4.3 Performance Testing

This procedure tests for the speed and effectiveness of the software being

developed. Quantitative tests will be performed in order to measure response time. There are
several tools in the market to perform these tasks. Due to the nature of the software developed
we will be using Apache JMeter which was originally designed to test web applications such as
traveling.com. This tool will allow us to test response speed on databases, queries, scripts as
well as simulate heavy loads on the server and the network. (opensourcetesting.org, n.d.)

4.4.4 Alpha Testing

The first test that will be performed for the travelling.com system will be in a

laboratory setting after the initial development-phase testing and the release testing are
performed. The main goal of these tests is to fix bugs that might be in the system as well as
ensure that the developer has being able to correctly interpret the customers requirements as
well as the visualization of the finished product. (pcmag.com, Alpha Testing, n.d.)

4.4.5 Beta Testing

After a successful alpha testing the software will be ready to enter the beta testing

stage in which the system will be tested by users under normal operating conditions. This stage
can be considered a review of all afore mentioned testing practices and is in place to ensure that
there are no circumstances that might put the systems functional integrity at risk. (Repurposed
from Software Design, Individual Project 5, Professor Brian Bertrand)

4.5 Requirement Traceability

Please refer to Appendix A

4.6 Test Method and Procedures

Requirements have identified and tests to verify the outcome of the requirements

are in place but there is the imperative need to check results of a test towards their possible
outcomes and/or specific situations. These situations are referred as test case scenarios. A test of
that nature provides with the different paths that a user can take while trying to complete a
transaction within the system and the possible outcomes that could be either positive or negative.

The following is a test case sample tied to REQ A from the RTM. You can refer to

complete list of all the tests divided by their category (unit, usability and system testing) in
Appendix A.

THIS PART IS THE "TEST

CASES"

Test Cases:

Test Case ID
& Test
Type/Method

Initial
environment
and
configuration,
initial state of
system
required for
this test

Action

Expe
cted
resul
ts

A
ct
u
al
R
e
s
ul
ts
(s
h
o
ul
d
b
e
bl
a
n
k
u
n
ti
l
t
e
st
is
r
u
n
)

Positive

User is in the
flight search
page

User chooses
a valid
departure/arri
val location,
date and time

Negative

User is in the
flight search
page

User chooses
a
departure/arri
val location
that is not
available

Positive

User is in the
flight search
page

User chooses
a departure
time that is
not available

Positive

User is in the
flight search
page

User chooses
a departure
date that is
not available

Should
show a
list of all
available
flights
from the
departure
location
to the
arrival
one at the
specified
date and
time

Should
prompt
user to
make
new
selection
and
display a
nonavailable
combinat
ion
message

Should
get a list
of all
available
flights
within a
4 hour
range
from the
original
request

Should
get a list
of all
departing
available
flights
within 1
day range
from the
original
request

Positive

User is in the
flight search
page

User chooses
a return date
that is not
available

Should
get a list
of all
returning
available
flights
within 1
day range
from the
original
request

The first line of our test case refers to the type test method used which can be

either positive or negative. There is always a pre-requirement in order for the system to be tested
in a specific state, i.e. the system cannot be tested for hotel booking capabilities if the user is in
the car rental page. Action refers to what the user decides to do with the system, i.e. a user might
decide to enter a letter when a number is expected. These types of issues are usually solved by
the implementation of validation routines before sending information to the server and it is
usually added as part of the system testing.
The next line represents what the expectations of the system are either in a positive or
negative situation. The last sets of boxes are marked after the tests are performed and are used to
educate the software development teams as of the corrections that need to be performed to the
system and its behavior. Travelling.com software will be tested using test scenarios and one will
be created for each requirement shown in Appendix A.

5. Regression Testing
5.1 Introduction

Regression testing refers to the process of testing new additions to a program to

ensure that previous programming works as intended with the implementation of the new
changes. Regression testing is mostly applied whenever a new version of the software is being
launched together with all its new capabilities (scribd.com, 2004). In the case of travelling.com
which will be launched in its first version it is likely that most of the components of the
regression testing plan will be performed as part of the integration testing.

5.2 Purpose

The purpose of the regression testing plan is to selectively retest the system after

modifications have been added to it. In other words, it will check that the old functionalities are
kept once the new ones are implemented. The proposed tests will only be executed if the Project
Management Team considers necessary to retest some of the scenarios included in the integration
phase. It should be noted that for issues that originated by existent data, part or all of the
conversion tests may need to be rerun in regression testing. (techtarget.com, regression testing,
n.d.)

5.3 Components Being Tested

The main requirement of the travelling.com software is to perform flight searches

from affiliated airlines, either by specific dates or date ranges. In addition to that, users have the
option of renting vehicles while travelling and/or book hotel rooms for as long as they need to as
long as it is within their travel itinerary.

These features put some constraints into the usage of the system. A person cannot

make a hotel booking unless they have selected a flight and the same applies for the car rental.
As you can see the flight search can exist as a stand-alone feature and while the other two
searches (hotel and car rental) are independent of each other they are tied to be travel boundaries
generated by the travel itinerary.

With that said you can understand the need to perform effective integration testing

that might evolve into regression testing if the Project Management Team considers it necessary
to guarantee its correct functionality and integration.

5.4 Regression Testing requirements

REQUIREMENT

The system shall

allow the user to
pick a flight
itinerary, rent a
car, decline the
feature of booking
a hotel room and
purchase his travel
package

21

Ensure that the user is

able to purchase a
flight+rent a car
combination

Purchase a travel
package with 1,2 or 3
options included

Test script ID

Test description
(generic condition being
tested)

System or
subsystem being tested

Type of test
(functional, security,
performance) Can be more
than one. (Test Method per
Dr. Stout Chat 6)

Input data sources

Expected results

Priority
(mandatory or critical;
important; desirable)

THI
S
PA
RT
IS
TH
E
SC
RIP
T

Functional

Online user interface

User should be able

to purchase a flight,
car rental and decline
hotel booking

Critical


Pass/Fail criteria
(allowable delta between
degree of mismatch
between actual and
expected results)

Traceability (ties
back to functions, modules,
data structures)

No tolerance

REQ N

REQUIREMENT

The system shall

allow the user to
pick a flight
itinerary, decline
renting a car, book
a hotel room and
purchase his travel
package

22

Ensure that the user is

able to purchase a
flight+hotel
combination

Purchase a travel
package with 1,2 or 3
options included

Test script ID

Test description
(generic condition being
tested)

System or
subsystem being tested

Type of test
(functional, security,
performance) Can be more
than one. (Test Method per
Dr. Stout Chat 6)

Input data sources

Expected results

Traceability (ties
back to functions, modules,
data structures)

THI
S
PA
RT
IS
TH
E
SC
RIP
T

Functional

Online user interface

User should be able

to purchase a flight,
book a hotel and
decline renting a car

Critical

No tolerance

REQ O

Priority
(mandatory or critical;
important; desirable)

Pass/Fail criteria
(allowable delta between
degree of mismatch
between actual and
expected results)

REQUIREMENT

The system shall

allow the user to
pick a flight
itinerary, rent a
car, book a hotel
room and purchase
his travel package

23

Ensure that the user is

able to purchase a
flight+rent a car +
hotel combination

Purchase a travel
package with 1,2 or 3
options included

Test script ID

Test description
(generic condition being
tested)

System or
subsystem being tested

Type of test
(functional, security,
performance) Can be more
than one. (Test Method per
Dr. Stout Chat 6)

Input data sources

Expected results

Traceability (ties
back to functions, modules,
data structures)

THI
S
PA
RT
IS
TH
E
SC
RIP
T

Functional

Online user interface

User should be able

to purchase a flight,
car rental and book a
hotel

Critical

No tolerance

REQ L

Priority
(mandatory or critical;
important; desirable)

Pass/Fail criteria
(allowable delta between
degree of mismatch
between actual and
expected results)

REQUIREMENT

The system shall

allow the user to
pick a flight
itinerary, decline
renting a car,
decline booking a
hotel room and
purchase his travel
package

24

Ensure that the user is

able to purchase a
flight itinerary

Purchase a travel
package with 1,2 or 3
options included

Test script ID

Test description
(generic condition being
tested)

System or
subsystem being tested

Type of test
(functional, security,
performance) Can be more
than one. (Test Method per
Dr. Stout Chat 6)

Input data sources

Expected results

Functional

Online user interface

User should be able

to purchase a flight
without having to rent
a car or book a hotel

Priority
(mandatory or critical;
important; desirable)

Pass/Fail criteria
(allowable delta between
degree of mismatch
between actual and
expected results)

Traceability (ties
back to functions, modules,
data structures)

THI
S
PA
RT
IS
TH
E
SC
RIP
T

Critical

No tolerance

REQ A

REQUIREMENT

The system shall

send a
confirmation email
to the user after a
purchase. The
email information
is based on the
travel package
purchased and the
data generated by
the affiliated
partners

25

Test script ID

Test description
(generic condition being
tested)

Ensure that an email

with relevant
information is sent

System or
subsystem being tested

Confirmation email is
sent

Type of test
(functional, security,
performance) Can be more
than one. (Test Method per
Dr. Stout Chat 6)

Input data sources

Expected results

Functional

Online user interface

User should receive

an email confirmation
which includes
information on the
package purchased.

Priority
(mandatory or critical;
important; desirable)

Pass/Fail criteria
(allowable delta between
degree of mismatch
between actual and
expected results)

Critical

No tolerance

THI
S
PA
RT
IS
TH
E
SC
RIP
T


Traceability (ties
back to functions, modules,
data structures)

REQ G

 5.5 Test Strategy

Regression tests have been identified and tests to verify the outcome of the

requirements are in place with the use of test case scenarios. The following are the test cases that
will apply to travelling.com system if regression tests are required.

Test ID 21

THIS PART IS THE "TEST

CASES"

Test Cases:

Test Case ID
& Test
Type/Method

Initial
environment
and
configuration,
initial state of
system
required for
this test

Action

Expe
cted
resul
ts

A
ct
u
al
R
e
s
ul
ts
(s
h
o
ul
d
b
e
bl
a
n
k
u
n
ti
l
t
e
st
is

r
u
n
)

Positive

Negative

User has chosen

a flight

User chooses
a car rental
company.

User chooses
to rent a car
from/to dates
that are not
within his
travel
itinerary.

User has chosen

a flight

Positive

User has chosen

a flight

User declines
the choice of
renting a car
while
travelling.

Positive

User has chosen

a flight and car
rental

User chooses
to purchase
his package.

Should
show a
list of all
available
rental car
companie
s with
vehicles
available
on the
arrival
location
for the
dates of
stay.

Should
show an
error
message
and allow
him to
make a
new
selection.

Should
allow the
user to
the next
choice
(hotel
booking).

Should
be taken
to the
payment
processin
g
company
to
complete
his
purchase.

Test ID 22

 THIS PART IS THE "TEST

CASES"

Test Cases:

Test Case ID
& Test
Type/Method

Positive

Initial
environment
and
configuration,
initial state of
system
required for
this test

User has chosen

a flight

Action

User declines
renting a car
and chooses
to book a
hotel room

(s
h
o
ul
d
b
e
bl
a
n
k
u
n
ti
l
t
e
st
is
r
u
n
)

Expe
cted
resul
ts

Should
show a
list of all
available
hotels
with
rooms
available
on the
arrival
location
for the

A
ct
u
al
R
e
s
ul
ts

dates of
stay.

Negative

User has chosen

a flight

Positive

User has chosen

a flight

User chooses
to book a
hotel room
from/to dates
that are not
within his
travel
itinerary.
User declines
the choice of
booking a
hotel room
while
travelling.

Positive

User has chosen

a flight,
declines a car
rental and
chooses to book
a hotel room.

User chooses
to purchase
his package.

Should
show an
error
message
and allow
him to
make a
new
selection.

Should
allow the
user to
the check
out

Should
be taken
to the
payment
processin
g
company
to
complete
his
purchase.

Test ID 23

THIS PART IS THE "TEST

CASES"

Test Cases:

Test Case ID
& Test
Type/Method

Initial
environment
and
configuration,
initial state of
system
required for
this test

Action

Expe
cted
resul
ts

A
ct
u
al
R
e
s
ul
ts
(s
h
o
ul
d
b
e
bl
a
n
k
u
n
ti
l
t
e
st
is
r
u
n
)

Positive

User has chosen

a flight

Negative

User has chosen

a flight

Negative

User has chosen

a flight

User chooses
a car rental
company and
a hotel

User chooses
to rent a car
from/to dates
that are not
within his
travel
itinerary.

User chooses
to book a
hotel room
from/to dates
that are not
within his
travel
itinerary.

Positive

User has chosen

a flight, car
rental and hotel
room.

User chooses
to purchase
his package.

Should
show a
list of all
available
rental car
companie
s with
available
vehicles.
Should
show a
list of all
available
hotels
with
rooms
available.

Should
show an
error
message
and allow
him to
make a
new
selection.

Should
show an
error
message
and allow
him to
make a
new
selection.

Should
be taken
to the
payment
processin
g
company
to
complete
his
purchase.

Test ID 24

THIS PART IS THE "TEST

CASES"

Test Cases:

Test Case ID
& Test
Type/Method

Initial
environment
and
configuration,
initial state of
system
required for
this test

Action

Expe
cted
resul
ts

A
ct
u
al
R
e
s
ul
ts
(s
h
o
ul
d
b
e
bl
a
n
k
u
n
ti
l
t
e
st
is
r
u
n
)

Positive

User has chosen

a flight

User declines
a car rental
option

Positive

User has chosen

a flight

User declines
to book a
hotel after
declining
renting a car

Positive

User has chosen

a flight

User decides
to cancel the
transaction

Positive

User has
cancelled the
transaction

User refuses
to login.

Prompt
the user
to book a
hotel
room

Should
be taken
to the
payment
processin
g
company
to
complete
his
purchase.

User is
prompted
to login,
so his
search
can be
kept
saved in
the
system
for him
to come
at a later
time.

Transacti
on is
cancelled
.
Searches
are
discarded
.

Test ID 25

THIS PART IS THE "TEST

CASES"

Test Cases:

Test Case ID
& Test
Type/Method

Initial
environment
and
configuration,
initial state of
system
required for
this test

Action

Expe
cted
resul
ts

A
ct
u
al
R
e
s
ul
ts
(s
h
o
ul
d
b
e
bl
a
n
k
u
n
ti
l
t
e
st
is
r
u
n
)

Positive

User has
purchased a
travel package

Negative

User has
purchased a
travel package

Travel
information
is presented
on the screen.

User
provided
with
incorrect/out
dated email
information

Positive

User has
purchased a
travel package

User
provided
with
incorrect/out
dated email
information

An email
which
includes
his travel
informati
on just
presented
on the
screen
should be
generated
and sent
to the
email
address
on file.

Confirma
tion
email
cannot be
sent.

Travel
informati
on is
available
when
user logs
in and
immediat
ely
prompts
him to
update
email
address.


The last sets of boxes will be checked after the tests are performed and are used to
educate the software development teams as of the corrections that need to be performed to the
system and its behavior. Travelling.com software will be tested using test scenarios if deemed
necessary by the Project Management team.

5.6 Test Schedule

As stated before, regression tests will be performed as needed and should be a

complement for the integration testing procedures that were already presented in section 4.3.2.
The Project Management Team has the last call as of if the inclusion of the tests is relevant and
cost effective for the project.

6. Compatibility
6.1

Hardware Compatibility

Travelling.com will be developed using PHP as the back-end programming

language; MySQL as the database and a HTML compliant design. This approach works
independently of the platform from which it is run. It is designed to perform either on a Linux or
a Windows server. There is some bandwidth specification to take in consideration but no issues
with hardware compatibility. There has never been a previous version of the travelling.com
software thus there is no need to create legacy backwards compatibility.

The hosting plan for travelling.com will be provided by webhost4life.com

premium plan which gives clients unlimited storage space, unlimited bandwidth, PHP 5 support
and plug-ins capabilities, MySQL databases (unlimited), unlimited FTP accounts, SSL
Encryption, IIS7/IIS6 servers, and many other features that might become useful in the future as
there is the need to add new features to the site. (webhost4life.com, n.d.)

6.2

Software Compatibility

The servers that will provide the hosting for the system are compatible with the

technology being used thus there are no additional software compatibility issues to be noted at
the time.

6.3

Network Compatibility

Users accessing travelling.com do not have any restrictions or requirements to visit the

website. Any legacy computer system should be enough as long as it has installed Internet
Explorer version 6 or newer or any other browser such as Opera, Google Chrome or Safari. The
clients bandwidth will have a direct effect on how fast they obtain the responses to their
searches. The performance testing for requirements B, C, P and Q are based on connection

speeds of 15mbps downstream and 2mbps upstream which is a regular home based cable internet
connection. (optimum.com, n.d.)

7. Summary

Many tests strategies and approaches have been presented in this document with the
intention of depicting to travelling.com management the efforts and precautions that will be
taken in consideration when developing the proposed system. Our own experience and proven
record show us that when testing starts in the early stages of development (unit, integration, etc.)
costs are reduced and delivery time is maintained throughout the project.
Test efforts might seem extensive, time consuming and redundant up to a certain degree
but we can assure you that their purpose to the life of the development process is imperative.
Our Quality Assurance team will be more than happy to assist you with any additional inquiries
you might have concerning the testing stages of the project as well as accepting your suggestions
and modifying functionality as the development progresses.

8. Reference Material

admin. (2011, January 19). Investment in Usability Testing is Investment in End-user

Satisfaction. Retrieved January 15, 2012, from blog.applabs.com:
http://blog.applabs.com/index.php/2011/01/investment-in-usability-testing-is-investmentin-end-user-satisfaction/

Duvvur, S. (2009, January 15). Test Planning Process. Retrieved January 23, 2012, from
csqa.info: http://csqa.info/cste_--_6._test_planning_process

guru99.com. (n.d.). Tutorial 29: Black Box Testing . Retrieved January 18, 2012, from
guru99.com: http://www.guru99.com/black-box-testing.html

Heckman, L. W. (2008, August 25). White Box Testing. Retrieved January 18, 2012, from
openseminar.org: http://openseminar.org/se/modules/46/index/screen.do

opensourcetesting.org. (n.d.). Apache JMeter. Retrieved December 19, 2011, from

opensourcetesting.org: http://www.opensourcetesting.org/performance.php

optimum.com. (n.d.). Get download speeds of up to 15 Mbps. Retrieved February 11,

2012, from optimum.com: http://www.optimum.com/home-internetservice/broadband/faster-internet.jsp

Parekh, N. (n.d.). Software Testing - Black Box Testing Strategy. Retrieved January 18,
2012, from buzzle.com: http://www.buzzle.com/editorials/4-10-2005-68349.asp

Perry, W. (2006). Effective Methods for Software Testing. Indianapolis: Wiley Publishing,
Inc.

Ramdeo, A. (2011, May 5). Installation Testing. Retrieved January 15, 2012, from
testinggeek.com: http://www.testinggeek.com/installation-testing

scribd.com. (2004, March 18). Regression Test Plan Template. Retrieved February 4,
2012, from scribd.com: http://www.scribd.com/doc/9825047/Regression-Test-PlanTemplate

softwarecertifications.org. (2011). Certified Software Tester: (CSTE). Retrieved January

15, 2012, from softwarecertifications.org: http://softwarecertifications.org/qai_cste.htm

techtarget.com. (2007, February). Unit Testing. Retrieved December 19, 2011, from
techtarget.com: http://searchsoftwarequality.techtarget.com/definition/unit-testing

techtarget.com. (n.d.). regression testing. Retrieved February 4, 2012, from

techtarget.com: http://searchsoftwarequality.techtarget.com/definition/regression-testing

usability.gov. (n.d.). Usability Testing. Retrieved January 23, 2012, from usability.gov:
http://www.usability.gov/methods/test_refine/learnusa/index.html

webhost4life.com. (n.d.). Windows Hosting. Retrieved February 11, 2012, from

webhost4life.com: http://www.webhost4life.com/webhost4life/windows-hosting.bml

 Appendix A

Requirement Tracing Matrix (RTM)

Traceabilit
y Matrix

The
system
shall allow
the user
to choose
data, time
and
departure
arrival
location
for flights
The
system
shall
return a
flight
search
based on
an specific
date in 6
seconds or
less
The
system
shall
return a
flight
search
based on
a date
range in
11
seconds or
less
Enter
existent
login
informatio
n
Interface

Allo
w
use
rs
to
sec
urel
y
logi
n/cr
eat
ea
ne
w
use
r

Allow
users
to
perfor
ma
flight/
hotel/
car
rental
searc
h

Allow
users
to
book
and
purch
ase
airpla
ne
ticket
s/car
rental
s/hot
el
booki
ng
base
d on
their
choic
e

Obt
ain
Res
erv
atio
n
nu
mb
ers
and
con
firm
tran
sact
ions