American International University-Bangladesh (AIUB)

Department of Computer Science

Faculty of Science &Technology (FST)
Spring 23 24
Section:B
Software Quality Assurance and Testing
Digital payment system with QR code technology for public
transportation in Dhaka
A Report submitted
By

SN Student Name Student ID

1 Jamilur Reza Sayed 20-42579-1
2 Kazi Iftekhar Rahman 20-42696-1
3
4

Checked By Industry Personnel

Name:

Designation:

Company:

Sign:

Date:
Software Test Plan

for
Digital payment system with QR code technology for public
transportation in Dhaka

Version 1.0 approved

Prepared by <Jamilur Reza Sayed, Kazi Iftekhar Rahman>

<American International University-Bangladesh>

<10/05/2024>
Table of Contents
Revision History............................................................................................................................... 3
1. TEST PLAN IDENTIFIER: RS-MTP01.3 ............................................................................... 4
2. REFERENCES ........................................................................................................................... 4
3. INTRODUCTION ...................................................................................................................... 4
Background to the Problem ...................................................................................................................... 4
Solution to the Problem ............................................................................................................................ 4
4. REQUEIREMNT SPECIFICATION ......................................................................................... 5
4.1 System Features............................................................................................................................. 5
4.2 System Quality Attributes ............................................................................................................. 7
4.3 System Interface ............................................................................................................................ 9
4.4 Project Requirements .................................................................................................................. 11
5. FEATURES NOT TO BE TESTED ........................................................................................ 12
6. TESTING APPROACH ........................................................................................................... 12
6.1 Testing Levels ............................................................................................................................. 12
6.2 Test Tools.................................................................................................................................... 13
6.3 Meetings ...................................................................................................................................... 13
7. TEST CASES/TEST ITEMS ................................................................................................... 13
8. ITEM PASS/FAIL CRITERIA ................................................................................................ 14
9. TEST DELIVERABLES.......................................................................................................... 24
10. STAFFING AND TRAINING NEEDS ................................................................................... 25
11. RESPONSIBILITIES ............................................................................................................... 26
12. TESTING SCHEDULE ........................................................................................................... 26
13. PLANNING RISKS AND CONTINGENCIES....................................................................... 26
14. APROVALS ............................................................................................................................. 27

Revision History
Revision Date Updated by Update Comments
0.1 13/04/2024 Jamilur Reza Sayed First Draft
0.2 23/04/2024 Kazi Iftekhar Rahman Second Draft
0.3 29/04/2024 Kazi Iftekhar Rahman Third Draft
0.4 30/04/2024 Jamilur Reza Sayed Final Draft
1. TEST PLAN IDENTIFIER:RS-MTP01.3

2. REFERENCES
[1] "Digital Payment System with QR Code Technology for Public Transportation in Dhaka,"
Software Requirements Specification Document, [20 December,2023]

ৃ ক্ষ-গণপ্রজার্ন্ত্রী বাাাাংলাদেশ
[2] Public-Bus-Fare-of-Dhaka Metro বাাাাংলাদেশ সড়ক পরিবহন কর্তপ
রসকার (brta.gov.bd)

3. INTRODUCTION

Background to the Problem

Dhaka, a megacity, stands out among its global counterparts due to the absence of a comprehensive
design or guideline governing the operation and extension of its public transport system. The total
number of buses is 11,060, while the number of minibuses is 8,583. Among a total of 160 bus
routes, 140 routes are now in service. It is noteworthy that 88% of these active routes are being
managed by 137 distinct bus firms. An estimated 21 million individuals engage in daily
commuting by various forms of public transit, with the bus emerging as the most frequently
utilized method of travel. Approximately 44.7 percent of the daily excursions mostly pertain to
employment, whereas 17.7 percent are specifically associated with school and are made by bus.
The total additional revenue derived from the quantity can be conceptualized. Based on the data,
it can be concluded that a significant portion of those who rely on buses for their everyday
transportation would experience advantages by adopting an effective digital payment system
utilizing QR codes.

Solution to the Problem

The existing payment system for buses in Dhaka, Bangladesh operates on a cash basis, wherein
passengers are required to remit a fare of 2.15 taka per kilometers for both long-haul buses and
minibuses. Nevertheless, as a result of the conductors' incapacity to offer exact change, customers
frequently find themselves paying a higher amount than the designated fare. This issue poses a
substantial challenge for passengers and results in additional financial burdens. In order to tackle
this matter, the adoption of a digital payment system including QR code technology can offer
passengers a payment mechanism that is both more convenient and efficient. QR code payments
offer travelers a convenient means of settling their fares, alleviating concerns associated with the
need to carry physical currency or locate precise denominations. This approach is expected to
provide benefits not only for passengers but also for bus operators by enhancing operational
efficiency and streamlining processes. The implementation of a digital payment system utilizing
QR code technology has the potential to greatly enhance the transportation infrastructure in Dhaka,
hence offering a more efficient and satisfactory commuting experience for the substantial
population of 21 million individuals who rely on public transportation daily.
4. REQUEIREMNT SPECIFICATION

4.1 System Features

1. User Registration and Authentication
• Functional Requirements
1.1 Users shall be able to register for an account by providing necessary details such
as name, phone number, email, and address.
1.2 Registration shall require authentication through email or phone verification.
1.3 Users shall be able to securely log in using a username/email and password.
1.4 Password requirements shall include a minimum length, inclusion of uppercase
and lowercase letters, numbers, and special characters.
• Priority Level: High
• Precondition: User has valid user id and password.

2. QR Code Generation and Scanning

• Functional Requirements

2.1 The system shall generate unique QR codes for each transaction or ticket. 2.2
Passengers shall be able to scan QR codes displayed by transportation operators to
make payments.

2.3 QR codes shall contain encrypted payment information and route details.

• Priority Level: High

• Precondition: QR code scanning device is available and operational.

3. User Registration and Authentication

• Functional Requirements
3.1 Integration with payment gateways shall enable secure transactions.
3.2 Support for various payment methods including credit/debit cards, mobile wallets,
and net banking shall be provided.
3.3 Real-time transaction tracking and confirmation for users and operators shall be
available.
3.4 Automated fare calculation based on distance traveled or fixed rates shall be
implemented.
• Priority Level: High
• Precondition: Payment gateway integration is completed and tested.

4. Route Planning and Information

• Functional Requirements
4.1 Display of available transportation routes, schedules, and fares shall be provided.
4.2 Integration with GPS shall provide real-time vehicle tracking and arrival times.
 4.3 Notification system for route changes, delays, or disruptions shall be implemented.
4.4 Option to plan multi-modal journeys involving different modes of transportation
shall be available.
• Priority Level: High
• Precondition: GPS integration is functional and routes are properly configured.

5. Account Management
• Functional Requirements
5.1 Users shall be able to update their personal information and payment preferences.
5.2 Option for users to view transaction history and download receipts shall be
provided.
5.3 Transportation operators shall be able to manage their accounts, vehicles, and
routes.
5.4 Administrators shall be able to manage user accounts, permissions, and system
settings.
• Priority Level: High
• Precondition: User accounts are properly set up and permissions are configured.

6. Accessibility and Multi-Language Support

• Functional Requirements
6.1 User interface shall be designed to be accessible to people with disabilities.
6.2 Support for multiple languages to cater to diverse users in Dhaka shall be provided.
6.3 Option for text-to-speech and screen reader compatibility shall be available.
• Priority Level: High
• Precondition: Accessibility features are tested and verified.

7. Security and Privacy

• Functional Requirements
7.1 Implementation of encryption protocols to secure user data and transactions shall
be ensured.
7.2 Regular security audits and updates to protect against cyber threats shall be
conducted.
7.3 Compliance with data protection regulations such as GDPR shall be maintained.
7.4 Anonymization of personal data to protect user privacy shall be implemented.
• Priority Level: High
• Precondition: Security measures are in place and compliance is ensured.

8. Security and Privacy

• Functional Requirements
 8.1 Integration with existing ticketing systems for seamless fare collection shall be
provided.
8.2 Dynamic pricing based on demand, time of day, or special events shall be
implemented.
8.3 Option for passengers to purchase and store digital tickets on their accounts shall
be available.
• Priority Level: High
• Precondition: Ticketing systems are integrated and fare structures are configured.

9. Feedback and Support

• Functional Requirements
9.1 Feedback mechanism for users to report issues, suggest improvements, or provide
compliments shall be provided.
9.2 Customer support channels including email, chat, and phone for assistance shall
be available
9.3 Knowledge base or FAQ section to address common queries and troubleshooting
steps shall be provided.
• Priority Level: High
• Precondition: Support channels are set up and operational.

4.2 System Quality Attributes

Non-Functional Requirements:
There are two types of perspective of quality attributes.
First one is user perspective. There are 8 important primarily quality attributes to user
perspective.

1. Availability: Every day from 12:00 am to 11:59 pm local time, the system must be at least
98.5 percent available.

2. Efficiency: For this system to function effectively, at least 3.5 percent of the processing
capacity, 1.7 MB/S of disk space, 120 MB of memory, and 512 kbps of communication
bandwidth must be available.
3. Flexibility: Within three hours, a maintenance programmer with at least eight months of
experience should be able to add new features and functions, test the system, and make code
updates.

4. Integrity: User-entered password and an email verification code are required for two-step
user login verification.

5. Interoperability: When registering on the system, users are required to provide basic details
such as their email address, phone number, and user name. Therefore, the system must validate
the data, regardless of whether the user provided the data. Because of this, the system will be
able to import accurate data that corresponds to the information provided by the user.
Information from the local electoral commission office will be imported into the system.

6. Reliability: The maximum number of experimental runs that the system can lose is three
out of 800.

7. Robustness: The system must have a low downtime and high availability to guarantee that
passengers may conveniently access services and make payments on a regular basis. Establish
uptime goals (e.g., 99.5%) for essential features such as account management, fare payment
processing, and QR code scanning.

8. Usability: User interface (UI) should be easy to use, straightforward, and accommodating
to a wide range of users, including those with different degrees of technical literacy and
accessibility requirements. Make proper use of icons and visual signals, consistent layout, and
unambiguous labeling your top priorities. If the system is meant to be used on smartphones or
tablets, then it should follow best practices for mobile UI design.

And the last one is developer perspective.

There are important primarily quality attributes to developer perspective:

I. Maintainability: After eight months of training, maintenance programmers ought to be able

to resolve system problems on their own in three hours.

II. Portability: Any platform or operating system, such as Windows, Linux, Android, Apple,
Unix, Ubuntu, Haiku, Rhapsody, etc., must be supported by the system.

III. Reusability: System features must be created with sensible usage in mind for other
systems.

IV. Testability: Specific time constraints should be met by system operations, such as payment
being done in 15 seconds, the display of notification in 2 seconds etc.

Besides these two perspectives, there are also some quality attributes. Like:

I. Performance: User shall be able to confirm the payment within 15 seconds.

II. Learnability: The system user interface should be clearly and simply structured and free
of all dead weight. It should explain to the user what the software system should do.
 III. Readability: When a programmer will build the system with code. The code shall have to
be well structured should be use comment, should be maintain the code alignment. This is that
for reason when another programmer will see the system code that the programmer shall able
to understand the codes very easily without any hassle.

IV. Scalability: The system shall able to handle load increases without decreasing performance
or the possibility to rapidly increase the load.

4.3 System Interface

 Y:4i! I r ). rt, of s. tc. :'I fli4it.M l'-"' rru:n.t .s. st"rnl. -Bi91 a. pa Ml ,t s :;:t'"m
USER PAYME T USER PAYMENT ROUTE PLANNING

Conlh1r1..11«1n OiP:J lnerit

.,\\'AILA.D.L.E ROUTES:

Cre1li1Cnrd Number. 0••• 1254 -Rcru1 B

QR...i.

1) Q1•.:r,I 1.irn ri, r ra i91ta. f' 'llt:1 t s st'E:m

CCO T SETTINGS HELP D S PPORT USER PAYMENT

Pr.JtliC,N,til.lN'l'Olli\l,\ 10.._ rnt,,T,\CT l"'lll)IU,l,\'flnN'

NAME: Joh, r.,, T,ulul Amuan1: 2(1To1h

JtillONE:(117• ....·••;,.31

1"1\0:NE:{ll•111--.:.,••11•n

TI1.:i1t11 p111./mt:l"I s1.1- tcm iq1h.l r,.i.1.1mcnt s,_stcm

ACCESSIBILITY SETTINGS NOTIFICATION

,ew otificatiln1:

C111IIJrQ;,I: l)a.rl -Route Change

()1-1'

Drt■■lt Srtdnp Vlnr All Notiflcatian

4.4 Project Requirements
Our primary goal in project management operations is to deliver the product on time, within budget,
and with the necessary caliber. The main challenges are those of time, money, scope, resources,
and environment. Our task needs to be finished on time, within budget, and by the deadline. We
also need to give the system the required functionality. It is imperative that we uphold and
proficiently oversee the essential assets. We will achieve a good outcome if we manage each
limitation effectively.

Time Estimation:

• A practical solution should be available within 14 weeks.

• The development team will work 12 hours per day.
• Total working hours: 1220 hours.
• Total days needed: 101 days or approximately 3.5 months.

Storage Requirement:

• The program should not consume more than 100 MB of storage after installation.

Development Environment:

• Developers are preferred to use Visual Studio Code for coding, but alternative editors are
also acceptable.
• Git will be the primary code management and version control system.
• Source code will be hosted on GitHub for collaboration among developers.
• Unit testing will be performed using Selenium.
• Interactive prototyping will be done using Figma.

Resources:

• app developers.
• software testers.
• Custom Built PCs.
• Android smartphones.
• LAN Connection for network communication.

Language & Database:

• Programming Language: Java, Dart.

• Mobile UI Framework: Flutter.
• Database: MySQL.
 Environment:

• Office space will be required for development and collaboration.

Budget:

• Total budget: 3,50,000 BDT.

• Total Development Time: 3.5 Months or 14 Weeks.

5. FEATURES NOT TO BE TESTED

All the Features in this software need to be tested.

6. TESTING APPROACH

6.1 Testing Levels

Our testing approach will consist of several levels, starting from Unit testing and progressing through
Integration testing, System testing, and concluding with Acceptance testing. Each level will involve specific
testing activities and will ensure that the software meets the required quality standards before deployment.

Unit Testing:

Unit Testing will be conducted by individual developers responsible for each module or component.
Developers will create and execute test cases to validate the functionality of their code.
Test results, including test case lists, sample outputs, and defect information, will be documented
and reviewed by the development team leader.
Approval from the development team leader is required before the unit testing is considered
complete.

Integration Testing:

Integration Testing will focus on verifying the interactions between different modules or features
of the system.
Various integration strategies such as the sandwich strategy, big bang approach, bottom-up
integration, and top-down integration will be employed.
The development team leader will oversee the integration testing process and ensure accurate data
transmission between modules.

System Testing:

Once unit testing and integration testing are completed, the quality assurance team will perform
System Testing. System Testing will involve validating the entire system against customer
specifications. Both functional and non-functional testing, including volume, load, and
performance testing, will be conducted at this level. Black box testing methods will be used to
ensure comprehensive test coverage.

Acceptance Testing:
 Acceptance Testing will be carried out by actual end users in collaboration with the test manager
and development team leader.
This testing phase will involve real-world scenarios to validate the system's readiness for
deployment.
Acceptance testing will run in parallel with the existing manual payment process for a period of
one month after the completion of System/Integration testing.
Feedback from end users will be collected and incorporated into the final release of the system.

6.2 Test Tools

The only test tools to be used are the standard AS/400 provided utilities and commands.

o The Program Development Manager (PDM) will be used as the source version configuration
management tool in conjunction with the in-house check-in/check-out control utility. The check-in/out
utility is part of each developer’s standard AS/400 access menu.

o Initial prototypes for the new screens will be developed using the AS/400 Screen Design Aid (SDA).
The initial layout and general content of the screens will be shown to the sales administration staff prior
to proceeding with testing and development of the screens.

6.3 Meetings
Every week, the quality assurance team leader will set up a meeting to assess the progress being made on our
application. We will also regularly perform code reviews and code walks through in order to find errors and bugs
as soon as possible. Each week our project manager will meet with our quality assurance team lead to go over
the status of our project. Every two weeks, all of our staff members who are involved in the project will
participate in the inspection section.

7. TEST CASES/TEST ITEMS

 Table 1: Test Case for User Registration and Authentication

Project Name: Digital payment system with QR code technology Test Designed by: Jamilur Reza
for public transportation in Dhaka Sayed

Test Case ID: DPST_REG_001 Test Designed date:13/04/2024

Test Priority (Low, Medium, High): High Test Executed by:Jamilur Reza
Sayed

Module Name: User Registration and Authentication Test Execution date:11-05-2024

Test Title: User Signup Process

Description: Test the application's registration page to see if the

user can successfully register their information.

Precondition (If any): The application must be accessible and functional.

Test Steps Test Data Expected Actual Status

Results Results (Pass/Fail)

1. Navigate to the Username: The As expected, Pass

registration [Username]<br>Password: registration
page. Enter [Password]<br>Email: process should
username [Email]<br>Phone be initiated
2. Click on the number: [Phone And a new user
"Sign Up" Number]<br>Address: should be
button [Address] registered.
3. Enter user
details in the
form.
4. Click on the
"Submit" button
Post Condition: The user should be successfully registered in the system.
 Table 2: Test Case for QR Code Generation and Scanning
Project Name: Digital payment system with QR code technology Test Designed by: Jamilur Reza
for public transportation in Dhaka Sayed

Test Case ID: DPST_QR_001 Test Designed date:13/04/2024

Test Priority (Low, Medium, High): High Test Executed by:Jamilur Reza
Sayed

Module Name: QR Code Generation and Scanning Test Execution date:11-05-2024

Test Title: QR Code Generation Process

Description: Test the system's functionality to generate unique

QR codes for each transaction or ticket.

Precondition (If any): The system must be operational and accessible

Test Steps Test Data Expected Results Actual Results Status

(Pass/Fail)

1. Initiate a • N/A •A unique QR • As Pass

transaction or • N/A code should be expected,
ticket purchase • N/A generated. • As
2. Display the • The QR code expected,
generated QR should contain • As
code encrypted expected,
3. Attempt to payment
scan the QR information and
code route details.
• The QR code
should be
scannable and
readable.
Post Condition: The QR code should contain valid payment information and route details.
 Table 3: Test Case for Payment Processing

Project Name: Digital payment system with QR code technology for Test Designed by: Jamilur Reza
public transportation in Dhaka Sayed

Test Case ID: DPST_PAY_001 Test Designed date:13/04/2024

Test Priority (Low, Medium, High): High Test Executed by:Jamilur Reza
Sayed

Module Name: Payment Processing Test Execution date:11-05-2024

Test Title: Payment Transaction Process

Description: Test the system's payment processing functionality

for various payment methods.

Precondition (If any): The system must be operational and accessible.

Test Steps Test Data Expected Results Actual Results Status

(Pass/Fail)

• Payment • Payment • As Pass

1. Initiate a method: should be expected,
payment Credit/Debit processed • As
transaction. card securely. expected,
2. Verify real- • N/A • Transaction • As
time • Distance status should expected,
transaction traveled: be updated in
tracking. [Distance] real-time.
3. Test Time of travel: • Fare should
automated [Time] be calculated
fare Payment accurately.
calculation method:
[Payment
Method]

Post Condition: Payment transaction should be successfully completed and reflected in the system.
 Table 4: Test Case for Route Planning and Information

Project Name: Digital payment system with QR code technology Test Designed by: Jamilur Reza
for public transportation in Dhaka Sayed

Test Case ID: DPST_ROUTE_001 Test Designed date:13/04/2024

Test Priority (Low, Medium, High): High Test Executed by:Jamilur Reza
Sayed

Module Name: Route Planning and Information Test Execution date:11-05-2024

Test Title: Route Information Display

Description: Test the system's functionality to display available

transportation routes, schedules, and fares.

Precondition (If any): GPS integration is functional and routes are properly configured.

Test Steps Test Data Expected Results Actual Results Status

(Pass/Fail)

• N/A •
Available • As Pass
1. Access • Route:Route transportation expected,
route Name routes should • As
planning • N/A be displayed. expected,
section. • Route details • As
2. Select a including expected,
specific scheduling
route. and fair
3. Verify should be
real-time shown.
vehicle • Gps
tracking Integration
should
provide
accurate
vehicle
tracking.
Post Condition: Users should have access to comprehensive route information.
 Table 5: Test Case for Account Management
Project Name: Digital payment system with QR code technology Test Designed by: Jamilur Reza
for public transportation in Dhaka Sayed

Test Case ID: DPST_ACC_001 Test Designed date:13/04/2024

Test Priority (Low, Medium, High): High Test Executed by:Jamilur Reza
Sayed

Module Name: Account Management Test Execution date:11-05-2024

Test Title User : Account Update

Description : Test the system's functionality for users to update

their personal information and payment preferences.

Precondition (If any): User accounts are properly set up and permissions are configured.

Test Steps Test Data Expected Results Actual Results Status

(Pass/Fail)

• N/A • User account • As Pass

1 Access • New settings expected,
account information: should be • As
settings page. [Updated Data] accessible. expected,
2 Update • New • User • As
personal preferences: information expected,
information . [Updated should be
3 Modify Preferences] updated
payment successfully.
preferences • Payment
preferences
should be
modified as
specified.

Post Condition: User account information and preferences should be updated accordingly.
 Table 6: Test Case for Accessibility and Multi-Language Support
Project Name: Digital payment system with QR code technology Test Designed by: Jamilur Reza
for public transportation in Dhaka Sayed

Test Case ID: DPST_ACCESS_001 Test Designed date:13/04/2024

Test Priority (Low, Medium, High): High Test Executed by:Jamilur Reza
Sayed

Module Name: Accessibility and Multi-Language Support Test Execution date:11-05-2024

Test Title User : Accessibility Check and Language Selection

Description : Test the system's accessibility features and multi-

language support.

Precondition (If any): User interface design includes accessibility features and supports multiple
languages.

Test Steps Test Data Expected Results Actual Results Status

(Pass/Fail)

• N/A • User • As Pass

1. Test • Language: interface expected,
accessibility [Selected should be • As
features. Language] accessible to expected,
2. Verify people with
language disabilities.
selection • System
functionality should
display
content in the
selected
language.

Post Condition: Users should be able to navigate the system easily, regardless of disabilities, and
access content in their preferred language.
 Table 7: Test Case for Security and Privacy
Project Name: Digital payment system with QR code technology Test Designed by: Kazi Iftekhar
for public transportation in Dhaka Rahman

Test Case ID: DPST_SEC_001 Test Designed date:13/04/2024

Test Priority (Low, Medium, High): High Test Executed by: Kazi Iftekhar
Rahman

Module Name: Security and Privacy Test Execution date:11-05-2024

Test Title User : Data Encryption and Privacy Compliance

Description : Test the system's security measures and compliance

with privacy regulations.

Precondition (If any): Security protocols are implemented and privacy policies are adhered to.

Test Steps Test Data Expected Results Actual Results Status

(Pass/Fail)

• N/A • User data and • As Pass

1. Test data • Regulations: transactions expected,
encryption [GDPR] should be • As
protocols. encrypted for expected,
2. Verify security.
compliance • System
with privacy should
regulations comply with
specified
privacy
regulations.

Post Condition: User data should be securely encrypted, and the system should adhere to privacy
regulations.
 Table 8: Test Case for Ticketing and Fare Management

Project Name: Digital payment system with QR code technology for Test Designed by: Kazi
public transportation in Dhaka Iftekhar Rahman

Test Case ID: DPST_TICKET_001 Test Designed date:13/04/2024

Test Priority (Low, Medium, High): High Test Executed by: Kazi Iftekhar
Rahman

Module Name: Ticketing and Fare Management Test Execution date:11-05-

2024

Test Title User: Ticket Purchase and Fare Calculation

Description: Test the system's ticketing functionality and fare

calculation methods.

Precondition (If any): Ticketing system integration is completed and fare calculation algorithms are
implemented.

Test Steps Test Data Expected Results Actual Results Status

(Pass/Fail
)

• Ticket type: •User should • As Pass

1. Initiate a [Type]<br>Paymen be able to expected
ticket t method: [Method] purchase a ,
purchase • Distance traveled: ticket • As
2. Verify [Distance]Time of successfully expected
fare travel: . ,
calculatio [Time]Ticket type: • Fare should
n accuracy [Type] be
calculated
accurately
based on
distance and
time.
Post Condition: Ticket purchase should be successful, and fare calculation should be accurate.
 Table 9: Test Case for Feedback and Support

Project Name: Digital payment system with QR code technology for Test Designed by: Kazi Iftekhar
public transportation in Dhaka Rahman

Test Case ID DPST_FEEDBACK_001 Test Designed date:13/04/2024

Test Priority (Low, Medium, High): High Test Executed by: Kazi Iftekhar
Rahman

Module Name: Feedback and Support Test Execution date:11-05-2024

Test Title: Feedback Submission and Support Channels

Description: Test the system's functionality for users to provide

feedback and access customer support.

Precondition (If any): Feedback mechanism is implemented, and support channels are accessible.

Test Steps Test Data Expected Results Actual Results Status

(Pass/Fail)

• Feedback • Feedback • As Pass

1. Submit content: should be expected,
feedback [Content] submitted • As
through successfully. expected,
the • Channels: • Support
system. Email, channels
2. Access Chat, should be
customer Phone. accessible
support for
channels. assistance.

Post Condition: Feedback should be successfully submitted, and support channels should be
accessible for assistance.
 Table 10: Test Case for System Performance

Project Name: Digital payment system with QR code technology Test Designed by: Kazi Iftekhar
for public transportation in Dhaka Rahman

Test Case ID: DPST_PERFORMANCE_001 Test Designed date:13/04/2024

Test Priority (Low, Medium, High): High Test Executed by: Kazi Iftekhar
Rahman

Module Name: System Performance Test Execution date:11-05-2024

Test Title: System Response Time and Scalability

Description: Test the system's performance in terms of response

time and scalability.

Precondition (If any): System architecture is designed for performance optimization.

Test Steps Test Data Expected Results Actual Results Status

(Pass/Fail)

• N/A • System • As Pass

1. Measure • Load: response time expected,
system [Number of should be • As
response Transactions] within expected,
time. Users: acceptable
2. Test system [Concurrent limits.
scalability Users]. • System
under load should be
able to
handle load
without
performance
degradation.

Post Condition: System should exhibit acceptable response times and scalability under load.
8. ITEM PASS/FAIL CRITERIA
A method will be used to determine whether a test case item passes or fails: Recommendations will be made
after all test cases have been successfully completed. The team leader will make these decisions based on
the results of the trial. The software framework cannot be removed until all bugs are fixed. When the final
program is released, there will always be some bugs in the system. The test leader and project manager will
therefore make the decision on whether to release the program and which test numbers will pass. It is solely
the responsibility of the test lead and project manager. If 98% of the test cases are successfully completed
during the test session, then we will go for releasing the software.

9. TEST DELIVERABLES
The Software Quality and Testing Plan outlines the technical and managerial processes essential
for the development and delivery of the system.

Acceptance Test Plan:

• A comprehensive acceptance test plan will be developed, serving as a contractual

agreement between our project team and stakeholders. This plan will outline the criteria
and procedures for acceptance testing to ensure that the system meets the specified
requirements and user expectations.

System Integration Strategy:

• A system integration strategy will be formulated to seamlessly connect various computer

systems or software applications to the central digital payment system for public
transportation in Dhaka. This strategy will facilitate the functional interaction between
different components and ensure interoperability.

Unit Test Strategy:

• The unit test strategy will define the approach for testing individual units or components
of the system. It will detail the methods, tools, and criteria for conducting unit tests to
verify the correctness and functionality of each unit in isolation.

Screen Prototypes:

• Iterative screen prototypes will be developed to visualize the user interface design and
functionality of the digital payment system. These prototypes will undergo usability
testing and iteration to refine the user experience and ensure alignment with user
requirements.

Mockup Reports:
 • Mockup reports will provide a visual framework for presenting graphics, charts, and
illustrations related to system design, functionality, and performance. These reports will
assist in communicating design goals, system decomposition, and acceptance criteria to
stakeholders effectively.

Incident Reports:

• Incident reports will document any incidents, issues, or deviations encountered during
system development and testing. These reports will contribute to improving system
reliability, identifying best practices, and ensuring employee safety throughout the project
lifecycle.

Test Manual:

• A comprehensive test manual will be prepared, detailing the unit and system tests
conducted on the digital payment system before delivery. This manual will outline test
procedures, expected results, and criteria for test success.

Test Log:

• The test log will record events and activities during test execution, including the status of
each test checkpoint and any issues encountered. This log will provide a detailed record
of testing activities and help track progress towards project milestones.

Employee Turnover Report:

• An employee turnover report will summarize the turnover rate among project team
members and stakeholders. This report will analyze turnover trends, identify potential
impacts on project delivery, and inform workforce management strategies.

10. STAFFING AND TRAINING NEEDS

To ensure effective testing and seamless implementation, staffing and training requirements are as
follows:
Tester Assignment:
• Assign at least one full-time tester for system/integration and acceptance testing phases.
Part-time involvement initially, transitioning to full-time after four months if possible.
Training on EDI Interface:
• Provide developers and testers with training on basic operations of the EDI interface
for testing purposes.
• Operations staff to receive comprehensive training on EDI communications process
before final acceptance of the project.
Training for Sales Administration Staff:
• Train sales administration staff on new screens and reports introduced by the system for
effective utilization.
.
11. RESPONSIBILITIES

12. TESTING SCHEDULE

The following testing activities are listed in the project plan. The project plan timetable contains a list of the
exact dates and hours for each activity. A list of the people needed for each step is also included in the project
schedule and plan. The project manager, in collaboration with the development and test team leaders, will
organize the management, customer, test team, and development team employees required for each assignment.

Figure: Project Timeline (Using Zira)

13. PLANNING RISKS AND CONTINGENCIES

Risks Planning
Technical, programmatic, and process risks are identified and categorized as part of software risk
management, which then forms the basis of a plan that connects each to a mitigation approach.
Throughout the project, the project manager keeps an eye on risk. If any do, a particular owner takes
a mitigating step.
➢ Lack of encrypted data: Keep an eye on security and back up the data with highly
encryption.
➢ Attempt unauthorized access: Consecutively three failed login attempts in an hour, the user
will be restricted.
➢ Error in Functionalities: Regularly test the application and make a daily backup.
➢ Wrong SQL Command for Sensitive Data: Keep security scans and backups up to data.

Contingency Planning
A contingency plan in project management is a defined, actionable plan that is to be enacted if an
identified risk becomes a reality. It is essentially a “Plan B”, to be put in place when things go
differently than expected.
➢ Power outages: We can face the load shedding that's why we need to always ready a backup
power source.
➢ Network Failure: We will install two fiber optics connection from the different ISP as if one
will be work as back up of another.

14. APROVALS
Project Sponsor
Development Management
EDI Project Manager
RS Test Manager
RS Development Team Manager
Reassigned Sales
Order Entry EDI Team Manager