Table of Contents

1. INTRODUCTION.........................................................................................................1
2. SCOPE ...........................................................................................................................1
2.1 Functions to be tested..................................................................................................1
2.2 Functions not to be tested...........................................................................................1
3. QUALITY OBJECTIVES............................................................................................1
3.1 Primary Objectives......................................................................................................1
3.2 Secondary Objectives..................................................................................................2
4. TEST APPROACH ......................................................................................................2
5. ROLES AND RESPONSIBILITIES...........................................................................2
6. ENTRY AND EXIT CRITERIA..................................................................................3
6.1 Entry Criteria .............................................................................................................3
6.2 Exit Criteria.................................................................................................................3
7. SUSPENSION CRITERIA AND RESUMPTION REQUIREMENTS...................3
7.1 Suspension criteria......................................................................................................3
7.2 Resumption criteria.....................................................................................................3
8. TEST STRATEGY........................................................................................................4
8.1 QA role .........................................................................................................................4
8.2 Bug life cycle.................................................................................................................5
8.3 Testing types.................................................................................................................5
8.4 Bug Severity and Priority Definition.........................................................................6
Severity List........................................................................................................................6
Priority List .......................................................................................................................7
9. RESOURCE AND ENVIRONMENT NEEDS ..........................................................7
9.1 Testing Tools ...............................................................................................................7
9.2 Test Environment........................................................................................................7
10. TEST SCHEDULE......................................................................................................8
APPROVALS ....................................................................................................................8
TERMS/ACRONYMS .....................................................................................................9
 Test Plan
Project “Make Trip application”
Document Revision History
Date Version Description Author Reviewer Approver
07.08.2021 0.1 Test plan Linh Vuong

1. INTRODUCTION
Customer wants a perfect website, which passed the full cycle of manual testing. Given the
specificity of the site it is very important to have the same quality and the site.
The Test Plan has been created to facilitate communication within the team members. This
document describe approaches and methodologies that will apply to the unit, integration and
system testing of the http://www.Makemytrip.com, it is an online application and this application
can be used to book for a Car. This document includes the objectives, test responsibilities, scope,
schedule major milestones, entry and exit criteria and approach. This document has clearly
identified what the test deliverables will be, and what is deemed in and out of scope. The plan
identify the features to be tested, the futures not to be tested, the types of testing to be performed,
the personnel responsible for testing, the resources and schedule required to complete testing,
and the risks associated with the plan.
2. SCOPE
The primary purpose of the document is test the GUI and validating in report output as SRS
provided by customer
2.1 Functions to be tested
- GUI
- Search Cabs
- Performance
2.2 Functions not to be tested
- Not other than mentioned above in section 2.1

3. QUALITY OBJECTIVES
3.1 Primary Objectives
A primary objective of testing is to: assure that the system meets the full requirements, including
quality requirements (functional and non-functional requirements) and fit metrics for each
quality requirement and satisfy the use case scenarios and maintain the quality of the product. At
the end of the project development cycle, the user should find that the project has met or
exceeded all of their expectations as detailed in the requirements and it guarantees all these
operations can work normally in real business environment.

1
Any changes, additions, or deletions to the requirements document, Functional Specification, or
Design Specification will be documented and tested at the highest level of quality allowed within
the remaining time of the project and within the ability of the test team.
3.2 Secondary Objectives
The secondary objectives of testing will be to: identify and expose all issues and associated risks,
communicate all known issues to the project team, and ensure that all issues are addressed in an
appropriate matter before release. As an objective, this requires careful and methodical testing of
the application to first ensure all areas of the system are scrutinized and, consequently, all issues
(bugs) found are dealt with appropriately.
4. TEST APPROACH
The approach, that used, is Analytical therefore, in accordance to requirements-based strategy,
where an analysis of the requirements specification forms the basis for planning, estimating and
designing tests. Test cases will be created during exploratory testing. All test types are
determined in Test Strategy.
Test cases will be created
5. ROLES AND RESPONSIBILITIES
Role Staff Member Responsibilities
Project Manager 1. Manage the whole project
2. Acts as a primary contact for
development and QA team.
3. Responsible for Project schedule and
the overall success of the project.
4. Acquire appropriate resources
QA Lead/Test Lead 1. Participation in the project plan
creation/update process.
2. Planning and organization of test
process for the release.
3. Coordinate with tester/BA on any
issues/problems encountered during
testing.
4. Report progress on work assignments
to the PM
5. Acquire appropriate resources
Tester/QA 1. Understand requirements
2. Design test cases and Executing Test
3. Preparing RTM
4. Reviewing Test cases, RTM
5. Assign bug for developer team
6. Defect reporting and tracking
7. Retesting and regression testing

2
 8. Bug Review meeting
9. Preparation of Test Data
10. Coordinate with Test Lead for any
issues or problems encountered during
test preparation/execution/defect
handling.

6. ENTRY AND EXIT CRITERIA

6.1 Entry Criteria
 All the necessary documentation like: requirement specification document, design
document, test data, test plans document.
 All the standard software tools including the testing tools must have been successfully
installed and functioning properly
 The test environment such as, lab, hardware, software, and system administration
support should be ready.
 QA resources have completely understood the requirements
 QA resources have sound knowledge of functionality
 Reviewed test scenarios, test cases document and RTM
6.2 Exit criteria
 Test Results/reports (cost and schedule have been achieved)
 What function is tested, what function is not tested
 No high priority or severe bugs are left outstanding
 All high-risk areas have been fully tested, with only minor residual risks left
outstanding
 Defect Report
 Installation/ Test procedures guidelines

7. SUSPENSION CRITERIA AND RESUMPTION REQUIREMENTS

7.1 Suspension criteria
 The build contains many serious defects which seriously or limit testing progress
 Any changed sharply in requirements suggested by client
 Tools or test environment problems
 Assigned resources are not available when needed by test team
7.2 Resumption criteria
 The development team fixes all the failed cases.
 All other problems have been resolved
8. TEST STRATEGY
8.1 QA Roles
- Understand requirements
Understand SRS that provided by Client
Understand what client want, output of software
The quality of the product

3
- Design test cases and Executing Test
Design test cases based on SRS and this will cover all scenarios for requirements.

- Preparing RTM
QA will be preparing test matrix which maps test cases to respective requirement.
This will ensure the coverage for requirements.

- Reviewing Test cases, RTM

 Test Lead review test cases and test matrix that have done by Tester
 Author will get any comments and suggestion from QA Lead on test cases and test
matrix
 Author will redo test cases and test matrix if it is not suitable or not satisfy the
requirement
 Re-worked improvements will be reviewed and approved by reviewer

- Executing Test Cases:

 Test execution based on test cases
 Update test result in test case document (fail or pass)

- Assign bug for developer team

 After defining bugs, Tester will write bugs on a tool that manages bugs and assign
this bug to developer who is responsible for this function

- Defect reporting and tracking

 Make a defect report after execution testing and assign bugs for developer team
 Keep track of the progress of fixing bugs

- Retesting and regression testing

 Retesting for fixed bugs will be done by respective QA once it is resolved by
respective developer and bug/defect status will be updated accordingly. In certain
cases, regression testing will be done if required.

- Preparation of Test Data:

 Test data will be created by respective QA on client's developments/test site based on
scenarios and Test cases.

- Coordinate with Test Lead for any issues or problems encountered during test
preparation/execution/defect handling.

4
 - Deployment/Delivery:
 Once all bugs/defect reported after complete testing is fixed and no other bugs are
found, report will be deployed to client’s test site by PM.
 Once round of testing will be done by QA on client’s test site if required Report will
be delivered along with sample output by email to respective lead and Report group.
 QA will be submitting the filled hard copy of delivery slip to respective developer.
 Once lead gets the hard copy of delivery slip filled by QA and developer, he will send
the report delivery email to client.
8.2 Bug life cycle:
All the issues found while testing will be logged into Word document.
8.3 Testing types
- Functional testing:
It check the behavior of the application. The characteristic of functional testing are to
provide correctness, reliability, testability and accuracy of the report output/data.
- Black box testing:
It is some time called behavioral testing or Partition testing, BVA. This kind of testing
focuses on the functional requirements of the software. It enables one to derive sets of
input conditions that that will fully exercise all functional requirements for a program.
- GUI Testing:
GUI testing will includes testing the UI part of report. It covers users Report format, look
and feel, error messages, spelling mistakes, GUI guideline violations.
- Integration Testing:
Integration testing is Test the interaction between each module. In Report, integration
testing includes the testing Report from respective location(s).
- System Testing:
System testing of software is testing conducted on a complete, integrated system to
evaluate the system's compliance with its specified requirements.
- Performance Testing:
Performance testing is the practice of evaluating how a system performs in terms of
responsiveness and stability under a particular workload. Performance tests are typically
executed to examine speed, robustness, reliability, and application size. It is conducted to
evaluate the compliance of the system or component with specified requirement
 Check the optimal time the page is loaded

5
  Check the operation of the system under load

- Regression testing: To ensure that there are no side of effects after a change and make
sure the defect have been removed

- User acceptance testing:

The purpose behind user acceptance testing is to conform that system is developed
according to the specified user requirements and is ready for operational use. Acceptance
testing is carried out at two levels - Alpha and Beta Testing. User acceptance testing will
be done at the Client.
- Alpha testing:
The alpha test is conducted at the developer's site by client.
8.4 Bug Severity and Priority Definition
Bug Severity and Priority fields are both very important for categorizing bugs and
prioritizing if and when the bugs will be fixed. The bug Severity and Priority levels will
be defined as outlined in the following tables below. Testing will assign a severity level
to all bugs. The Test Lead will be responsible to see that a correct severity level is
assigned to each bug.
The QA Lead, Development Lead and Project Manager will participate in bug review
meetings to assign the priority of all currently active bugs. This meeting will be known as
“Bug Triage Meetings”. The QA Lead is responsible for setting up these meetings on a
routine basis to address the current set of new and existing but unresolved bugs.
Severity List
ID Severity Description
1 Critical This defect indicates a complete shut-down of the process,
nothing can proceed further. The module/product crashes or
the bug causes nonrecoverable conditions. System crashes, GP
Faults, or database or file corruption, or potential data loss,
program hangs requiring reboot are all examples of a Sev. 1
bug..

2 High Major system component unusable due to failure or incorrect

functionality. Sev. 2 bugs cause serious problems such as a
lack of functionality, or insufficient or unclear error messages
that can have a major impact to the user, prevents other areas
of the app from being tested, etc. Sev. 2 bugs can have a work
around, but the work around is inconvenient or difficult.

3 Medium It causes some undesirable behavior, but the system is still

functional. Incorrect functionality of component or process.
6
 There is a simple work around for the bug if it is Sev. 3.
4 Minor It won't cause any major break-down of the system
Documentation errors or signed off severity 3 bugs.

Priority List
ID Level Description
1 High This bug must be fixed immediately; the product cannot
ship with this bug.

2 Medium During the normal course of the development activities

defect should be resolved. It can wait until a new
version is created.
3 Low Priority It is not important that these bugs be addressed. Fix
these bugs after all other bugs have been fixed.
Enhancements/ Good to have features incorporated-just
are out of the current scope.

9. RESOURCE AND ENVIRONMENT NEEDS

9.1 Testing Tools
Process Tool
Test case document Microsoft Excel
Test case tracking Microsoft Excel
Test case execution Manual, auto tools
Test case management Microsoft Excel
Defect report Microsoft Word
Test report PDF
Check list Microsoft Excel
Project structure

9.2 Test Environment

- Support level 1 (browsers):
 Window: Edge, Chrome (latest), Firefox (latest), Safari (latest)
 Mac OS X: Chrome (latest), Firefox (latest), Safari (latest)
 Linux Ubuntu: Chrome (latest), Firefox (latest)

- Support level 1 (devices):

 Android, Iphone, iPad: App based on network

- Support level 2:
 Anything else

7
10. TEST SCHEDULE
Task Name Start Time Finish Time Effort Comments
Test Planning 1.08 3.08 3 days
Review Requirements 1.08 3.08 3 days
documents
Create test cases 4.08 5.08 2 days
Create test basis 5.08 10.08 5 days
First deploy to QA test 10.8
environment
Functional testing – 10.08 13.08 3 days
Iteration 1
Iteration 2 deploy to 14.08 15.08 2 days
QA test environment
Functional testing – 16.08 26.08 10 days
Iteration 2
System testing 26.08 29.08 4 days
Regression testing 30.08 31.08 2 days
Resolution of final
defects and final build
testing
Deploy to Staging
environment
Performance testing
Compatibility testing
Security testing
User acceptance
testing
Release to Production

APPROVALS:
Project Manager QA Lead
Name
Signature

8
TERMS/ACRONYMS

API Application Program Interface

GUI Graphical user interface
PM Project manager
QA Quality Assurance
RTM Requirements Traceability Matrix