pi

Spicejet - Test Plan

 Spicejet 4.7 MAHESH.D

Revision History
4.7_UseCases_TestCases_Features_Interim
Reference Version No. 4.7
Build 9-24

Release Date Total No. of pages

Name Designation Date

Prepared by MAHESH QA Lead 19-Oct-2010

Reviewed By

Approved by

2 G-tech cyber solutions pvt.Ltd

 Spicejet 4.7 MAHESH.D

Table of Contents

INTRODUCTION 5

1. OBJECTIVE 5
1.1. Scope of Testing 5
5

2. REFERENCE DOCUMENTS 6

3. TEST ITEMS 6

3.1 . Features to be tested 6

3.2 Features Not to be Tested

4. TEST STRATEGY 6

4.1. Testing Types 6

4.1.1 Functional Testing 6

5. AUTOMATION TESTING 7
Understanding the product and verify the stability of the product: 8
Design Automation Framework: 8
Developing proof of concept: 8
Designed the Automation Frame work: 9
Automation Frame work implementation: 9
Development and Execution of the Script: 9

6. TEST ENVIRONMENT 10

7. ITEM PASS / FAIL CRITERIA 10

8. DEFECT ANALYSIS AND CLOSURE 11

9. THE TEST DELIVERABLES ARE: 11

10. RISKS AND CONTINGENCIES 11

11 HARD WARE AND SOFTWARE REQUIREMENTS

12 RESOURCE PLAN

3 G-tech cyber solutions pvt.Ltd

 Spicejet 4.7 MAHESH.D

4 G-tech cyber solutions pvt.Ltd

 Spicejet 4.7 MAHESH.D

5 G-tech cyber solutions pvt.Ltd

 Spicejet 4.7 MAHESH.D

Introduction
The Test Plan has been created to communicate the test approach to client and team members. It
includes the objectives, scope, schedule, risks and approach. This document will clearly identify
what the test deliverables will be and what is deemed in and out of scope.

1. Objective
The primary objective of this document is to establish a Test Plan for the activities that will verify
SPICEJET as a high quality product that meets the needs of the SPICEJET business community.
These activities will focus upon identifying the following:
 Items to be tested
 Testing approach / Strategy adopted
 Resource Requirements
 Roles and Responsibilities
 Milestones
 Risks and contingencies
 Test deliverables

1.1. Scope
This document is a very high level vision of how SPICEJET applications will be tested and will not
aim at providing any details about each testing engaged at various levels of testing.

Scope of Testing

1. Test cases identification and documentation for the new features/use cases and NFR

2. Creation of new test cases and updating existing test cases for all modules
3. Functional Testing for the new functionalities(New Features)

4. Non Functional Requirement(NFR) testing(Performance testing)

5. Regression testing for the SPICEJET functionalities

6. Complete SPICEJET Application testing

7. Recording of bugs and verification of resolved bugs for each build

6 G-tech cyber solutions pvt.Ltd

 Spicejet 4.7 MAHESH.D

2. Reference Documents
The table below identifies the documents and their availability, used for developing the test plan

Document Created / Received / Author /

(Version / Date) Available Reviewed Resource Remarks
Homepage SRS doc BA

Book a flight SRS doc BA

3. Test Items
3.1 .Features to be tested
All change requests / enhancements / bug fixes on above listed applications will be tested on need-
Basis:
Test cases will be prepared based on the following documents:
 Understanding Use Casedocuments
 Software design documents
 Data Validation documents

Business
Ref. No. Feature Functional Specification
Requirements

3.2 . Features not to be tested

Security Testing and mobile testings are not part of the engagement

4. Test Strategy
The SPICEJET modules and sub modules testing will be performed with below testing types

4.1. Testing Types

4.1.1 Functional Testing

The primary functional areas in various SPICEJET modules will be thoroughly tested according to
the functional specification document or understanding document or software requirement
7 G-tech cyber solutions pvt.Ltd
 Spicejet 4.7 MAHESH.D

specification document. During the testing phase, complete functionality will be tested at least
two to three times based on the complication involved in the application.

Ensure that each function specified in the functional

Test Objective
document and SRS works correctly while passing/retrieving
parameters without data corruption.
Test the each function by providing the valid and invalid
input values and inspect the input data has been operated
by the function, also inspect the output data as intended,
Technique
and ensure that all implemented functions are processing
the data properly or review the output data to ensure that
the correct data was retrieved.
Both interfaces (back-end application and end user site)
Completion Criteria should process data correctly without any mismatch. Error
handling cases should also be checked.
Testing may require the huge test inputs to test the
Special Considerations functionality of sending test SMS or test e-mails.

5. Automation Testing
This section describes the strategy and the activities performed as part of the planned strategy for
implementing the automation of test scenarios. The following steps should be adopted as a part of
strategy of implementing the test automation

8 G-tech cyber solutions pvt.Ltd

 Spicejet 4.7 MAHESH.D

Understanding the product and verify the stability of the product:

First analyze the product and assess the feasibility of automating the test scenarios identified for application. It i
also ascertain that the future releases of the product would not undergo major changes.

Design Automation Framework:

Based on the product, evaluation of various test automation tools with an objective to suggest a suitable
automation tool in all respects should undertaken.

Developing proof of concept:

A proof of concept developed to show the capabilities and computability of the tool with the application.
In the POC we have taken AOA and BBM scenarios by covering the various verification points and actions.

9 G-tech cyber solutions pvt.Ltd

 Spicejet 4.7 MAHESH.D

Design the Automation Frame work:

To design the Frame Work we use the Data Driven Approach as the applications are stable and no GUI
changes are identified and which would also cover AUT( Application Under Test).This also identifies the
various reusable action and common steps.

Automation Frame work implementation:

In this all the identified reusable function are implemented followed by coding convention.

Development and Execution of the Script:

The test scripts are developed based on design. Finally, a clear log report is produced covering all the
verification points. Adherence to the define coding conventions and elimination of common coding.

Automation – Phases ACTIVITIES DELIVERABLES

Automation Assessment  Walkthrough of  Plan for Framework phases.

requirements.
 Walkthrough of systems.
 Analyze requirements from
automation perspective.
 Focused discussions
- Preparing test cases
- Test data requirement
- Test data conditioning
- Technical aspects
- Priorities
- Workarounds
Framework Design  Identification of test  Detailed design document
scenarios for automation.  Test Scenarios with
 Identification of Reusable coverage’s to be automated.
components.
 Preparing Design document.
Framework Development  Prepare framework code  Baseline Design document
 Code reviews  Framework code
 Testing framework

Test scenarios Automation  Develop automated script  Automated Test scripts

based on the framework  Automate Manual User
developed Guide.
 Test data conditioning input
file preparation
 Testing of the automated
script.
 Peer review of the scripts for

10 G-tech cyber solutions pvt.Ltd

 Spicejet 4.7 MAHESH.D

adherence to standards.
 Prepare User manual guide.
 Package the automated
scripts for release

Testing Tool: Selenium

6. Test Environment
The test environment preparation step will ensure that hardware, software, and tools required
for testing will be available to the testing team when they are needed. This would involve co-
ordination with IT infrastructure team and other providers in regard to Equipment, Operating
systems, networks, etc.

Machine type : Windows server Enterprise

OS : Windows
Processor : Intel® xeon® CPU
Memory : 4 GB / 2.13 GHZ
Hard disk : 150 GB
Database : Microsoft SQL Server 2008 Standard Edition
Web server : IIS 7.0
Client /Browser : Microsoft Internet Explorer, Firefox, GoogleChrome

7. Test Pass / Fail Criteria

Defects will be classified as follows according to severity of the impact on the system:

*Severit
Description
y Level
Calico Software is not operational in production and a work-around is not
available. Critical Errors include the following:
Sev 1 - Blocker • Calico Software may cause corruption or destruction of data
• The System fails catastrophically (50% or greater reduction of service)
• Two or more reboots of the System per day
A major function in the Calico Software is not operational and no acceptable
work-around is available, but Customer is able to do some production work.
High Errors include the following:
Sev 2 –Very High • System is usable but incomplete (one or more documented
commands/functions are inoperable/missing)
• System fails catastrophically (10-50% reduction of service)
• One reboot per day of the System
There is a loss of a function or resource in Calico Software that does not
seriously affect the Customer’s operation or schedules. Medium Errors include
the following:
Sev 3 - High
• Issues associated with the installation of Calico Software
• Any “Critical” or “High” Error that has been temporarily solved with a work-
around

11 G-tech cyber solutions pvt.Ltd

 Spicejet 4.7 MAHESH.D

All other issues with Calico Software. Low Errors include the following:
Sev 4 - Suggestion • Errors in Documentation
• Calico Software does not operate strictly according to specifications

8. Defect Analysis and closure

Following are the defect tracking activities till its closure. It includes:

 Logging of defects

 Analysis of defects

 Fixing of defects

 Re-testing of fixes

 Regression testing to ensure that fixes have not impacted the original functionality.

 Defect tracking till closure

9. The Test Deliverables:

Phase DeadLines (Date
No Modules of Delivery)
1. BookaFlight
2. ManageMy Booking
1 3. PNR Status 30th Jun
2 4. Flight Schedules 31st July
5. Corporate Benefit
3 6. Spice connect 30th Sept

10.Risks and Contingencies

Risks Contingencies
Resource shortfall Maintain buffer resources
Continuous Requirement Changes Analyze the requirements
Lack of peer reviews Monitor Peer reviews

11. HARD WARE AND SOFTWARE REQUIREMENTS

Desktops with Windows OS -- 10
Laptops with Mac OS– 8

12 G-tech cyber solutions pvt.Ltd

 Spicejet 4.7 MAHESH.D

Mobiles Android & IOS -- 2

12. RESOURCE PLAN

Test Engg- 10
Automation Engg’s – 8
DB Engg - 2

13. TEST SUMMARY REPORT / BUILD POST MARTUM REPORT

 No of Builds released by Dev Team - 50
 No of Builds accepted by testing team - 25
 No of Builds rejected by testing team - 25
 No of test cases prepared by testing team - 1000
 P1 - 500, P2- 350, P3-100, P4-50

 No of bugs identified - 400

o Blocker- 100
o Very High- 150
o High- 100
o Medium- 40
o Low- 10
 No of bugs identified by client- 100
o Blocker- 10
o Very High- 50
o High- 10
o Medium- 10
o Low- 20
 Success Stories
 Challenges

13 G-tech cyber solutions pvt.Ltd