Test_Plan_Template_02 1
Test_Plan_Template_02 1
Test_Plan_Template_02 1
ChangeLog
1. INTRODUCTION .....................................................................................................................................................2
2. PRE-REQUISITES ...................................................................................................................................................2
4. IN SCOPE ..................................................................................................................................................................2
1
RATHAM- TEST PLAN
1. Introduction
The Ratham TMS (Transport Management System) is a robust web application for its fleet management
system. It helps streamline scheduling, tracking, and reporting for various sectors like buses, taxi and
corporate shuttles. Designed for efficiency and ease of use, it supports better management of fleet
operations and enhances overall customer satisfaction. This Test Plan details all the testing activities
that are conducted to certify the web application and mobile application of this fleet management
system.
2. Pre-requisites
1. A client signed off BRD and approved Figma screens should be provided.
2. One round of sanity testing will be done to accept the application for testing.
3. A separate test environment needs to be given and the deployments will happen only after
necessary approvals.
4. All required test accounts need to be created and shared with the testing team.
3. Testing Artifacts
• Test Plan : It is a dynamic document which talks about all the testing activities and it is prepared at the initial
stage as soon as we get the requirement
• Test Cases : Test cases are the indetailed document which talks about all possible situations and multiple ways
to test the application.
• Requirement Traceability Matrix: It is used for mapping the requirement with written TC’s.
• Bug Reports: A bug report is a documented description of a software defect or issue
encountered during testing.
• Customer Sign Off: The client or end-user indicating acceptance of the software product
4. In Scope
This section lists all the activities that are carried out as part of the quality certification of the web and
mobile application.
2
RATHAM- TEST PLAN
The application will be certified in all the below listed types of testing along with the coverage scope in
each type of testing and the estimated time taken for each under ideal circumstances.
3
RATHAM- TEST PLAN
4
RATHAM- TEST PLAN
Driver App and Mobile App testing will be covered for functional testing.
Note: The above timelines hold good in ideal circumstances. In case of any issues during test preparation
and execution the time lines need to be revisited accordingly.
5. Out of Scope
Accessibility Testing, Database and API testing are out of scope for testing the Ratham TMS.
• QA Analysts:
QA Analyst is responsible for ensuring the quality of the software product through rigorous
testing and validation processes. They work closely with development teams to identify issues,
verify fixes, and ensure that the software meets specified requirements and standards before
deployment.
• Test Manager:
The Test Manager oversees the entire testing process, managing resources, schedules, and
activities to ensure that testing objectives are achieved efficiently and effectively.
• Developers:
Developers are responsible for designing, coding, and maintaining the software application
according to requirements and specifications.
5
RATHAM- TEST PLAN
7. Quality Objective
To ensure that the Transportation Management System (TMS) meets the defined functional and non-
functional requirements, adheres to quality specifications set by the client, and resolves identified
bugs/issues before the application goes live.
• Functional and Non-functional Requirements: Validate that all features and capabilities of the
TMS perform as specified in the functional and non-functional requirements documentation.
• Meeting Client's Quality Specifications: Ensure that the TMS meets the quality standards and
performance metrics expected by the client, thereby enhancing user satisfaction and
operational efficiency.
• Bug Identification and Resolution: Identify, prioritize, and rectify any bugs or issues discovered
during testing to minimize risks and ensure a stable application.
8. Test Methodology
Agile emphasizes flexibility and iterative development, with continuous collaboration between cross-
functional teams. It prioritizes customer feedback and adapts to changing requirements. We will adapt
the approach of Agile testing and implement bug fixes in the iterative approach and promise improve
quality with each iteration.
9. Bug Triage
The bug triage process aims to systematically identify, prioritize, and schedule resolution for all
reported issues in the TMS application
Bug Identification: Bugs are identified through testing phases such as UT, IT, ST, and UAT. Users may
also report bugs encountered during real-world usage.
Bug Logging: Each identified bug is logged in a bug tracking system (e.g., JIRA) with details including:
Type of Resolution:
6
RATHAM- TEST PLAN
Suspension Criteria:
Critical Bugs: If critical bugs are identified that significantly impact core functionalities or
prevent further testing progress.
EX: system crash or data loss
Infrastructure Issues: If there are issues with the test environment, such as server downtime or
network failures.
Resource Constraints: If there are insufficient resources (e.g., hardware, software licenses)
Resumption Requirements:
Resumption criteria determine when testing can resume after it has been suspended.
Bug Fix Verification: Testing will resume once all critical bugs causing application crashes are
fixed and validated.
Infrastructure Stability: once the test server is back online and accessible after scheduled
maintenance.
Resource Availability: once additional mobile devices are procured to continue mobile testing
activities.
Management Approval: Testing may require management approval to resume if significant
time has passed since suspension.
Testing Tools
7
RATHAM- TEST PLAN
Test Environment
It mentions the minimum hardware requirements that will be used to test the Application.
13. Terms/Acronyms
Make a mention of any terms or acronyms used in the project
TERM/ACRONYM DEFINITION
API Application Program Interface
AUT Application Under Test