Project Part 2

Software Quality Assurance

Prepared by:
Rawa Rebwar HamaAmin QU202SECJ013
Zheno Tahir
Shnyar Faeq
Danyar Omar
Las Sirwan

Lecturer:
Dr. Mohamad Shihab

Kurdistan Regional Government

Ministry of Higher Education and Scientific Research
Qaiwan International University
College of Engineering
Software Engineering Department
Introduction
Application Title
“TMT Bank Management System”

Application Features Introduction

TMT Banks is a Banking management system that is used to keep records of clients in a Bank, in which the admin
can create accounts for their customers upon their opening of a new bank account, and keep track of their
balance, the admin can withdraw, deposit and transfer money for their clients. This program is meant to be used
by the admin rather than clients. It uses a built-in backend SQLite database to securely store clients’ data and
keep them updated according to their bank accounts, whether they want to deposit or withdraw money from
their account or transfer money from their account to another. TMT Banks has been implemented in the Java
programming language and uses a lightweight GUI widget toolkit called swing.

Test Items (Components to be tested)

I. Create Account
II. Withdraw
III. Log On
IV. Transfer
List Of Functionalities
I. Create Account
II. Login Button
III. Seeing Profile of the users
IV. Edit Profile of the users
V. Deposit
VI. Withdraw
VII. View Balance
VIII. Transfer Money
IX. Customer List
X. Change Pin
XI. About
Software Risk Issues and Mitigations
Prior to beginning of the testing phase, risk should be assessed and appropriate measures should be
performed. Tester's approach to risk identification makes it possible to see potential problems early on.

Risk How to avoid risks or have a Plan B

1. Testing requirements Sticking to the original (current) requirements and moving

changing continuously the new requirements to the next phase of testing.

2. Tight deadline Demanding more resources (such as more specialized team

members to the testing roster)

3. Insufficient resources Being more efficient and effective

4. Predicting the You cannot really test every single user interaction before
unpredictable the release of any product however the software developers
can monitor and address bugs that arise during production
(when available for wide-use)

5. Limited Testing We cannot use automation Testing for this assignment and
that is a limitation that we have. The way we avoid it would
be by trying our test cases manually and we would spend
more time testing them.

1
Features to be tested
“Create Account” Component

Feature Description Level of

Risk

This feature allows the admin of the

system to register new clients into the

Create ( functional )
High
system.

storing the data efficiently in the

Efficiency Medium
database in a compressed form while

only using minimal resources such as

CPU, memory and storage.

2
“Withdraw” Component

Feature Description Level of

Risk

This featureshould allow theadmin of

thesystem to withdraw money from

Withdraw(functional)
High
the client.

The admin must be able to withdraw any

amountfrom thesystem. This requires

Compatibility High
thesystem to be able to exchange
(non-functional
information with the databaseand
)
updatethe databasebased on

theamount thattheadmin withdrew

from the client.

This also requires other componentsto

work together,such as the View

Balance Component, which should

reflect the changes thathave been

accrued in the database.

3
“Log On” Component

Feature Description
Level of

Risk

Log on(functional) High

This feature authenticates the people

that are using this system, and at the
same time is the gateway to the
system, without passing here you
cannot use other parts of the system
except for creating new accounts.

Reliability (non-functional) This component alongside most of the High

other components in the system needs

to be reliable almost all the time. So

testing for reliability would be one of our

biggest concerns

4
“Transfer” Component

Feature Description

Level of

Risk

This feature should allow the admin to

transfer money from one client to another.

Transfer(functional)

High

Security(non-functional) For a banking software that is High

concerned with a customer’s cash flow
and sensitive data, security would be
the first priority in the system to make
sure of, and the system is reliable to
use.

5
Features not to be tested
Functional Features:
I. Clear
II. Going Back
III. Dropdown Menu
IV. Check box
V. About
VI. Change pin
VII. Getting Date
VIII. Calculate
IX. Deposit
X. Edit Profile of the users
XI. Save
XII. View Balance
XIII. Transfer Money
XIV. Customer List

Non-Functional Features:
I. Scalability
II. Capacity

6
Approach or Strategy

We are using manual testing because we are not yet familiar with the other types of testing like
automation testing, unit or integration testing. We are not choosing Manual testing just because of our
limitations but because of its importance that you have to execute each test case and each feature that
you have identified, in your test plan manually, and this will allow us to be certain about the expected
behaviors from our features which could be functional or non-functional.
The first thing we would test will be the quality attributes and for the sake of clarity we won't write them
again. We do all the steps just like we have identified in our quality attribute testing steps on page 20 and
onwards.
After finishing the testing of the quality attributes, we are going to start with the functional features that
we have stated in our test plan to be tested, we are going to Start by testing the Creating Account
functionality and trying to test each scenario that might cause an error or a software failure, we are
estimating the time taken would be around 1 day to test this functionality fully. Then we are testing the
“Log On” functionality and test its different test cases because it is one of the most repetitive actions that
the user has to do on a daily basis,

After that we are testing the withdraw button manually and we will try to see if
the button will work as expected. The expected time for this task would be
around 12 hours to 1day, 1 Day maximum. Finally for the search functionality
because it is the least important in our priority list for the functional features,
we are going to test it at last, we assume that it would take us up to 1 day.Fun
After finishing testing of the functional features, we are going to test the non-functional features. Starting
with Security feature, normally non-functional features take more time to be tested rather than the
functional ones, so here we won’t rush the things we will be testing the Security feature along with the
Efficiency, reliability and compatibility for 15 days to ensure that we have tested the software in as many
possible scenarios as possible. And to ensure that our testing will go as planned we will try to use as many
devices as possible with different operating systems and in different locations around the world. We are
going to test Security and
Compatibility together because compatibility can be discussed when talking about security. About how we
approach these two, we have to analyze the code and look at the different modules and components
inside our system and see how they are connected and what their vulnerabilities are when it comes to
cyber-attacks and malware. For the other two we would be testing the system at different times while
trying to test their limits and understand their constraints and limitations.

7
Item Pass/Fail Criteria
Functional Features
I. Create: For the Create Account feature to pass the testing process it should successfully create a
new account and store its data in the database.
II. Withdraw: For the Car Age Selector to pass the testing processes it should be able to withdraw the
specified amount from the client when the user clicks the amount button.
III. Log on: For this feature to pass, it should be able to successfully log in to the system and
authenticate the user.
IV. Search: For this to succeed, all the information related to the username that the admin writes in the
textbox must be retrieved back to the user.

Non-Functional Features
I. Reliability: Our software system should be able to work in different conditions and at different
times successfully to pass our criteria.
II. Compatibility: Our software should be able to connect to the different parts of our system
architecture (database) and exchange information (data) to pass our criteria.
III. Efficiency: The system must be able to store the data efficiently in the database in a compressed
form and also use the least number of resources possible.
IV. Security: Since our system is to maintain a bank operation, it must be as secure as possible and not
be prone to data breaches and malicious attacks, to be invulnerable against cyber-attacks and
contain the least number of loopholes.

8
Environmental Needs

Computer to open the application

Enough Storage to store the Test data
Test Data that will help the testers to test based on these data
Software
Notion: Team management software for planning and keeping track of the ideas of the group members
Mero: is a whiteboard platform that will allow teams to collaborate with each other and share their ideas
together, it is suitable for teams who work with Agile.
Slack: for communication and sharing the required resources and files with other team members.
Code Editor: such as VSCode, Atom or sublime to run and test the code.
Lucid Chart: to draw the use case diagrams and activity diagrams.

Gmail: to contact the other team.

Messenger: to communicate with the other team and ensure that we are on the right track.
Canva Gantt Chart: We are using a software called Canva which is for designing diagrams, graphs and
charts. We use a Gantt chart to plan and schedule our project, in order to help us keep track of how long
the project should take, and in what order the tasks should be executed to complete the project.

Responsibilities

Planning & Staffing: Shnyar Faeq - Zheno Tahir

Introduction: Rawa Rebwar
Software Quality attribute: Las Sirwan
Test Plan: Rawa Rebwar
Manual Testing Functional Features: Shnyar Faeq
Manual Testing Non-Functional Features: Danyar Omer
Requirement Testing: Las Sirwan

9
Test Task and Schedules

10
 Date: May 12, 2023
Academic Session: 2022 – 2023 / i
Software Quality Assurance

11
TestLink Community [configure $tlCfg->document_generator->company_name]

Test Plan Execution Report (on specific build)

Test Project: QIU-Banking Management System

Test Plan: QIU-BMS-TC
Build: 01

Printed by TestLink on 12/05/2023

2012 © TestLink Community
Table Of Contents

1.1. Create Account

QIU-BMS-1: Create Account

1.2. Withdraw

QIU-BMS-2: Withdrawal

1.3. Log On

QIU-BMS-3: Log On

1.4. Transfer

QIU-BMS-4: Transfer
Test Plan: QIU-BMS-TC

Test plan for system testing of Banking Management System (BMS). This test plan will include all test cases related to all use
cases
1.1. Test Suite : Create Account

This feature allows the admin of the system to register new clients into the system.

Test Case QIU-BMS-1: Create Account

Author: QIU-BMS-Rawa

Summary:

This feature allows the admin of the system to register new clients into the system.
Preconditions:

The Software must be open and running.

Execution
#: Step actions: Expected Results: Execution notes:
Status:
Opening the
1 The program should start The Main Page Opened Passed
main page.
The system should open a
Clicking “New New page opened, with textboxes to
2 new window, when Passed
Account” Button. write user credentials
clicking new account
Type the correct Filling out the first name The system allows the user to
3 Passed
user credentials and last name write the credentials
The system automatically creates a
Typing password Filling out the password
4 password for the client. There is no Passed
& email and email
email needed.
Clicking the Save button,
Clicking “Save” Clicking the Create button,
5 shall create a new account Passed
Button. creates a new account.
for the user.
Execution type: Manual
Estimated exec.
duration (min):
Priority: Medium
Requirements None
Execution Details
Build 01
Tester QIU-BMS-Rawa
Execution Result: Passed
Execution Mode: Manual
Execution duration
6.00
(min):
1.2. Test Suite : Withdraw

This feature should allow the admin of the system to withdraw money from the client

Test Case QIU-BMS-2: Withdrawal

Author: QIU-BMS-Rawa

Summary:

This feature should allow the admin of the system to withdraw money from the client.
Preconditions:

A client must have an account

Execution
#: Step actions: Expected Results: Execution notes:
Status:
Starting the The program
1 The program starts Passed
program. should start
The system opens a new window and gives you
Login to the Log In to the
2 authority to use the functionaliti es of the Passed
system software
system
Clicking
Withdraw Going to the
3 The system opens the withdrawal window. Passed
Button in the Withdraw Location
toolbar.
The system must first finds the user and
The system lets
Writing the automaticall y fills out all the required
you to write the
4 Balance to be information for the client(User, Name, Failed
balance to be
withdrawn Account No., Available Balance), then you
withdrawn
can pass the balance to the system.
Writing the The system should
The system lets you write the name of the
5 name of the let you write the Passed
client.
client. name of the client.
Clicking the
Clicking the
“Withdraw” button, The system withdraws the specified amount
6 “withdraw” Passed
should withdraw the from the client.
button
written
Execution type: Manual
Estimated exec.
duration (min):
Priority: Medium
Requirements None
Execution Details
Build 01
Tester QIU-BMS-Rawa
Execution Result: Passed
Execution Mode: Manual
Execution duration
7.00
(min):
1.3. Test Suite : Log On

This feature allows the user to login to the system and access its functionalities.

Test Case QIU-BMS-3: Log On

Author: QIU-BMS-Rawa

Summary:

This feature allows the user to login to the system and access its functionalities.
Preconditions:

The user must have an account

Execution
#: Step actions: Expected Results: Execution notes:
Status:
Opening the
1 Opening Login page The Main Page Opened Passed
main page.
Writing the The system should let you write a The system lets you write
2 Passed
username correct username the Account Number
Writing the The system shall let you fill Out The system lets you to
3 Passed
password The password for the user write the PIN of the client
Clicking Login, shall open the The system opens the
4 Pressing Log in Passed
program. client’s page
Execution type: Manual
Estimated exec.
duration (min):
Priority: Medium
Requirements None
Execution Details
Build 01
Tester QIU-BMS-Rawa
Execution Result: Passed
Execution Mode: Manual
Execution duration
3.00
(min):
1.4. Test Suite : Transfer

This feature should allow the admin to transfer money from one client to another.

Test Case QIU-BMS-4: Transfer

Author: QIU-BMS-Rawa

Summary:

This feature should allow the admin to transfer money from one client to another.
Preconditions:

The User must have an account

Execution
#: Step actions: Expected Results: Execution notes:
Status:
1 Logging in Log In to the software Logs in to the user’s account Passed
Opening the Transfer Going to the location, The system opens the Transfer
2 Passed
window you can transfer in it. Window
Searching for the The system lets you
The system lets you write the
3 client’s name who write the client’s name Passed
username of the client
transfers money who transfers money
The system lets you write the
The system should let
Specifying the amount balance to be transferred, as well
4 you write the balance to Passed
to be transferred as giving you the ability to
be transferred
calculate the result.
Specifying The other
The system only takes
client that we want to The system only takes the second
5 the second user’s Failed
send the particular user’s account number.
account number.
balance.
Clicking the Send
Clicking the Transfer button, should send The system Transfers the
6 Passed
Button the balance to the specified amount
other client.
Execution type: Manual
Estimated exec.
duration (min):
Priority: Medium
Requirements None
Execution Details
Build 01
Tester QIU-BMS-Rawa
Execution Result: Passed
Execution Mode: Manual
Execution duration
6.00
(min):