Test_Plan_Template_02 1

Download as pdf or txt
Download as pdf or txt
You are on page 1of 9

RATHAM- TEST PLAN

TRANSPORT MANAGEMENT SYSTEM

ChangeLog

Version Change Date By Description

version 1 7-11-2024 Pavithra Initial version


Version 2 7-15-2024 Kranti Kada Added the timelines, updated
functionalities list and Team
structure .
RATHAM- TEST PLAN

TRANSPORT MANAGEMENT SYSTEM ...............................................................................................................0

1. INTRODUCTION .....................................................................................................................................................2

2. PRE-REQUISITES ...................................................................................................................................................2

3. TESTING ARTIFACTS ...........................................................................................................................................2

4. IN SCOPE ..................................................................................................................................................................2

5. OUT OF SCOPE .......................................................................................................................................................5

6. ROLES AND RESPONSIBILITIES .......................................................................................................................5

7. QUALITY OBJECTIVE ..........................................................................................................................................6

8. TEST METHODOLOGY ........................................................................................................................................6

9. BUG TRIAGE ...........................................................................................................................................................6

10. SUSPENSION CRITERIA AND RESUMPTION REQUIREMENTS .............................................................7

11. TEST COMPLETENESS.......................................................................................................................................7

12. RESOURCE & ENVIRONMENT NEEDS ..........................................................................................................7


TESTING TOOLS ...........................................................................................................................................................7
TEST ENVIRONMENT ....................................................................................................................................................8
13. TERMS/ACRONYMS ............................................................................................................................................8

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

S.No Testing Artifacts Start Date End Date


1 Test Plan 15 July 17 July
2 Test Cases 15 July 19 July
3 Requirement Traceablity 15 July 19 July
4. Test execution and Results 22 July 30 July
5. Bug reports 28 July 30 July
6. Sign Off 30 July 5 August

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.

S.No Type of Testing Coverage Scope Estimated Time


1 Functionality testing Functionality and data validation in each 5 Days
module
2 Integration testing Checking the relationship or dataflow 5 Days
between the dependent modules
3 Compatibility testing Chrome & Firefox 1 Day
4 User Interface Figma Vs Application 2 Days
Testing
5 System testing End to End Flow and Regression 1 Day
6 Security Testing Minimal Security testing 1 Day
7 App Testing Test the Driver (Android) and Employee App 5 Days
(both Android and iOS) on a total of 3 to 4
devices, including the latest version, the
oldest available version, and a mid-range
version of different OS (Oppo, Vivo, MI,
Samsung)

Modules covered under Testing scope

S.No Module Name Functionalities Testing


1.Username
2.Password
3.Reset password
1 Login Page/Profile 4.login with SSO
1.Drop down of centers and
Buildings
2.Search bars of emp id, cab id,
2 Dashboard trip id
1.Search bar
2.Add new center with center
details
3.1 Center Master 3And building details
1.Center dropdown
2.Shift type dropdown,
3.Search bar and
3.2 Shifts Master 4.Add new shift
1.Center dropdown
2.Search bar
3.Add new shift with personal
3.3 Employees Master info,

3
RATHAM- TEST PLAN

4.location info and


5.corporate info
6.Download template and choose
file
1.Center dropdown
2.Search bar
3.4 Vendors Master 3.Add new vendor
1.center and vendor dropdown
2.Search bar
3.Add new driver/vehicle
4.Download module in vehicles
3.5 vehicle and Driver Master master
1.Center dropdown
2.Search bar
3.6 Guard Master 3.Add new guard
1.Center dropdown
2.Search bar
3.7 Holiday Master 3.Add new holiday
1.Center dropdown
2.Search bar
3.8 Cost center Master 3.Add new cost center
1.Center dropdown
2.Search bar
3.9 Process & Subprocess Master 3.Add new process & sub process
1.Search bar
4.1 Device 2.Add new device
1.Route accuracy
5.1 Route Editor 2.Drag and Drop
1.Center dropdown
2.Shift type
5.2 Ops Management 3.View button.
1.Center dropdown, shift type,
5.3 Vehicle Allocation shift time and buildings.
1.Center drop down
2.Download Template
5.4 Roster Upload 3.Choose file
1. All Trips.
2. Delayed,
3.female travelling alone
4.Location violation,
5.In premises,
6.Non complaint vehicle
7.center dropdown
5.5 Tracking 8.shift dropdown.
1.Center dropdown and search
5.6 Route Manager bar

4
RATHAM- TEST PLAN

2.All routes with draft and


published and add new route
3.Nodal points
6.1 Message Templates
6.2 Reports

App Modules covered under Mobile App Testing

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.

6. Roles and Responsibilities

• 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.

Structure of the Test team

NAME ROLE % CAPACITY

Kranti Kada Test Manager 4 hrs

Pavithra QA Analyst 8 hrs

Abhisheik QA Analyst 3 hrs

5
RATHAM- TEST PLAN

Rohith QA Analyst 4 hrs

Bhargavi QA Trainee 2 hrs

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:

• Description of the issue


• Steps to reproduce
• Severity and priority

Type of Resolution:

6
RATHAM- TEST PLAN

• Fixed: Bug needs to be fixed by developers.


• Won't Fix: Issue does not need fixing based on project priorities or technical constraints.
• Duplicate: Similar issue has already been reported.
• Cannot Reproduce: Issue cannot be replicated based on provided information.
• Deferred: Bug is acknowledged but deferred to a future release or update.

10. Suspension Criteria and Resumption Requirements

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.

11. Test Completeness


Test Completeness criteria explaining its purpose and importance in ensuring the quality of the
application.
• 100% test coverage
• Execution of Test Cases
• Bug Closure for Release Planning
• Security Testing
• x Testing

12. Resource & Environment Needs

Testing Tools

• Test Management Tool: JIRA

7
RATHAM- TEST PLAN

• Test cases - Microsoft Office


• Test reports, Bug reprots and sign off – Microsoft Office

Test Environment
It mentions the minimum hardware requirements that will be used to test the Application.

Following software’s are required in addition to client-specific software.

• Windows 8 and above


• Office 2013 and above
• MS Exchange, etc.
• A

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

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy