Pls can any 1 temme the test cases for an online banking
proj. like account transaction summary, deposit module,
savings module



Pls can any 1 temme the test cases for an online banking proj. like account transaction summary, d..

Answer / saurabh kumar

3. Testing
The system comprisesof three modules. They are:
• Administrator.
• Account Holder.
• General User.

Module 1 – Administrator Module
Purpose
After proper login in to the system,the
administrator can do the following things:
• View Pending A/C opening applications.
• Viewing details of particular Account.
• Edit Press Releases.
• Edit Jobs listing.

a)Administrator login:
Input: The Admin is trying to log
into the system.
Output: Prompting for selecting options
given, like viewing Pending A/C opening
applications, edit Press Release, edit Jobs listing.
Detailed Algorithm:
• Administrator requests for
login.
• Validation for username and password is done.
• Response is given by showing him options to
access
various features.

b) Viewing pending applications and
accepting/rejecting them
Input: User logged in the system must be an
authenticated admin.
Output: Administrator should be
able to change the status of
the application.
Detailed algorithm:
• Administrator enters
username, password.
• Checking is done whether it is a
valid combination or not at the database.
• If exists in database
access is granted.
• Administrator requests for
Pending Account Opening Applications.
• The request is forwarded.
• Result is retrieved from
database.
• Summarized list is displayed to the administrator.
• Administrator selects
Particular application.
• Details are displayed to
the administrator with options to accept
or reject the
application.
• Administrator
accepts/rejects Application.
• This information is forwarded to the database.
• Changes are made in db.
• DB Updated.
• Updating is informed to
the Administrator.

c)Administrator posting news features
Input: User logged in the system must
be an authenticated administrator.
Output: Posting is done.
Detailed Algorithm:
• Administrator requests to
view news.
• News displayed.
• Administrator views news.
• Administrator may update
news by adding new news or
deleting old news.
• Corresponding updations are
performed at the database.

d) Administrator posts job features
Input: User logged in the system must be
an authenticated administrator.
Output: Job features are posted.
Detailed Algorithm:
• Administrator views the jobs.
• Administrator may add new jobs or delete old jobs.
• The corresponding changes are updated in the
database.

Module 2 –Account Holder module

Purpose:
After proper login in to the system, account
holder can do the following things:
i. View Balance
ii. Transferring funds
iii. Request for cheque book
iv. Previous transaction details
v. Change Password
vi. Request for Help

a)Login
Inputs: The Account Holder is trying
to log into the system.
Outputs: Prompting for selecting options
given, like changing Password,
changing Profile, viewing Account
Balance and previous transaction details,
making Transaction
Detailed Algorithm:
• Administrator requests for login.
• Validation for username and
password is done
• Response is given by showing him
options to access various features.

b)Forgot password
Inputs: user informs forgot password.
Outputs: New generated Password is sent
to the user through mail.
Detailed Algorithm:
• Account Holder is prompted with
secret question.
• Answer is accepted from the
Account Holder when creation of
account and it is verified
with the database.
• New password is generated and sent to him through mail.


c) view balance:
Inputs: User logged into system must be an
authenticated Account Holder.
Outputs: Account Holder views account balance.
Detailed Algorithm:
• Account Holder enters username, password.
• Checking is done whether it is a valid
combination or not at the database.
• If exists in database access is granted.
• Account Holder makes a request for viewing
Account Balance.
• The request is forwarded to the database.
• The result is retrieved from the database.
• Balance is viewed by the Account Holder.
d) Transferring funds:
Inputs: Account number of the account holder and
the amount to be transferred.
Output: Transaction is committed.
Detailed Algorithm:
• Account Holder enters username, password.
• Checking is done whether it is a valid combination or not
at the database.
• If exists in database access is granted.
e) Request for cheque book
Inputs: User logged into system must be an
authenticated Account Holder.
Outputs: Depending upon the user request issueing
of cheque book, stoping
of cheques are performed.
Detailed Algorithm:
• Account Holder enters username, password.
• Checking is done whether it is a valid combination or
not at the database.
• If exists in database access is granted.
f) Previous Transaction Details
Inputs: User logged into system must be an
authenticated Account Holder.
Outputs:Monthly and annual transaction details are
displayed.


Detailed Algorithm:
• Account Holder enters username, password.
• Checking is done whether it is a valid combination or
not at the database.
• If exists in database access is granted.
g) changing Password
Input: User logged into system must be an
Account Holder to use this option.
Output: Updation of password is done at
database.
Detailed Algorithm:
• Account Holder enters username,
password.
• Checking is done whether it is a valid
combination or not at the database.
• If exists in database access is granted.
• Account Holder requests for change in
password.
• Prompts for Old Password and new
password.
• Information is added and submitted.
• This information is forwarded to the
database.
• Details are stored in database.
• Database updation is informed.


h) Request for Help
Inputs: User logged into system must be an
authenticated Account Holder.
Outputs:Help is provided to the user
Detailed Algorithm:
• Account Holder enters username, password.
• Checking is done whether it is a valid combination or
not at the database.
• If exists in database access is granted.






Module 3 – General User Module

Purpose:
The general user opens the sites URL and can do the
following things:
• Account creation.
• Applying for jobs.
• Viewing news.
• Viewing static information about
the bank.
a)Account creation
Inputs: The GlobalBank site is opened.
Outputs: Stores the details of the applicant in the
dormant database with status as‘Pending’.
Detailed Algorithm:
• The General user makes a request for
opening New Account.
• Client side Validation of the fields
entered by user is done.
• The data is stored in the database for
approval by Administrator.
• Response is given by showing the user,
suitable message.

b)Applying for jobs
Inputs: The GLOBALBANK site is opened. And
user clicked on the appropriate job title.
Outputs: User views various jobs and applies if interested.
Detailed Algorithm:
• The user clicks on the job of
his interest.
• That user requested job details
will be displayed like, experience, skills
required, location of job,
etc.
c)Viewing News:
Inputs: The GLOBALBANK site is
opened. And user clicked on the news item.
Outputs: User views news in detail.
Detailed Algorithm:
• The user clicks on the news
headline.
• That user requested news details get displayed in
detail.
d)Viewing static information:
Inputs: The GLOBALBANK URL is typed in web browser.
Outputs: That GLOBALBANK home page
is displayed with the
all the links to further
information.
Detailed Algorithm:
• The user types GLOBALBANK URL in
web browser.
• The bank home page is displayed with the
options like Account
application form, News, Jobs, etc.
• The user can continue the surfing by
clicking on any of the displayed links to know much more
about the bank.


Test Plan
3.2.1 Input Validation
Test Name: Login without having an account
Objective: To test that those who are not having account,
are not able to login in to
the system.
Input: Give a login id and password, which do not belong to
any account holder.
Example: Login id: abcde
Password: *****
Expected Output: invalid user id/password.

Test Name: Login with incorrect password.
Objective: To test that those users who enter correct
password can go for further
transactions.
Input: Incorrect password is given.
Example: Password: ***** (incorrect password)
Expected Output: invalid user id/password.

Test Name: Password must contain at least 4 characters.
Objective: To make sure that users enter valid password of
given range.
Input: Give a password with less than 4 characters.
Example: password: ***
Expected Output:password length must be greater than 4.

Test Name:Name field should not be empty.
Objective: To make sure that user must fill his name when
opening account.
Input: give name field as null string.
Example: name: (null string)
Expected Output:name field should not be empty.

Test Name:Address field should not be empty.
Objective: To make sure that user must fill his address
when opening account.
Input: give address field as null string.
Example: address: (null string)
Expected Output:please fill in the address field.

Test Name:city field should not be empty.
Objective: To make sure that user must fill his city when
opening account.
Input: give city field as null string.
Example: city: (null string)
Expected Output:please fill in the city field.

Test Name:PIN code field should not be empty.
Objective: To make sure that user must fill pin code when
opening account.
Input: give pin code field as null string.
Example: pin code: (null string)
Expected Output:please fill in the pin code field.

Test Name:email id field should not be empty.
Objective: To make sure that user must fill his email id
when opening account.
Input: give email id field as null string.
Example:email id: (null string)
Expected Output:please fill in the email id field.

Test Name:phone field should not be empty.
Objective: To make sure that user must fill phone number
when opening account.
Input: give phone number as null string.
Example: phone number: (null string)
Expected Output:please fill in the phone number field.


Test Name:Secret question & answer fields should not be
empty.
Objective: To make sure that user must fill secret Question
& answer fields when opening account.
Input: give secret question & answer fields as null string.
Example: secret Question: (null string)
Secret answer:(null string)
Expected Output:please fill in the Secret question &
answer fields


Test Name: Passwords entered by user must match when
changing password.
Objective: To make sure that users enter correct pass word.
Input: User enters mis-matched passwords.
Example: Password: *****
Retype password: ******
Expected Output: User must be informed that passwords do
not match.
Test Name: E-mail id entered by user must be a valid one.
Objective: To make sure that users enter correct email id.
Input: User enters incorrect email id.
Example: email id: any id violating constraints such as id
succeeded by @ followed
by some text followed by .co. in or .com.
Expected Output: User must be informed that invalid email
id is entered.
Test Name: Phone number must be numbers only.
Objective: To make sure that users enter valid phone number.
Input: Give a phone number including characters.
Example: Give any number containing characters.
Expected Output: User must be informed that phone number
must contain numbers
only.
Test Name: Account holder should enter valid YOURBANK id
while transferring
funds.
Objective: To have valid transfer of funds.
Input: Give an invalid account number.
Example: to: any number which is not an existing account
number or any input which is
not a valid account number entry.
Expected Output: User is asked to enter valid YOUR BANK id.
3.2.2. Output Validation
Test Name: News or Jobs posted correctly by administrator.
Input: Administrator posts news or jobs.
Expected Output: Posted news or jobs are viewed by user in
the site’s URL.
Test Name: Proper updating of balance after transfers of
funds or deposit money in to
account or withdrawal of money from account.
Input: Account Holder transfers funds or deposit money or
withdraws money.
Expected Output: Balance must be displayed correctly based
on the committed
transactions.



3.2.3. Error Conditions
Input: Transfer money, more than existing balance , to an
account.
Output: User is informed of invalid transfer of money
between accounts.
Input: Transfer amount to a nonexistent account.
Output: User is informed of the absence of the account.
Input: Account holder tries to withdraw money more than the
current balance.
Output: User is informed of invalid withdrawal.
3.2.4. Performance Testing
Response will be obtained from the system within a minute.

Is This Answer Correct ?    14 Yes 2 No

Post New Answer

More Test Cases Interview Questions

How many bugs have u found in your project?

3 Answers  


What is transaction testing?

0 Answers  


How to write test cases for "open file dialog box" for ms word? Thanks a lot!

0 Answers  


write test cases for hospitality management system

0 Answers   Infosys,


Please let me know how to write a test case for Digital Watch. Please any body can give the answer

9 Answers   Hewitt,






how many checkpoint u have to used

3 Answers  


How to write test case for this scenario. If the Zip Code field is populated, the system shall compare  the zip code value entered to the zip code value in  the Family Individual Information Tab

0 Answers  


write a testcase for tea cup?

6 Answers  


Pls tell me test cases for pepper grinder

0 Answers  


plz.. tell me hw to write the Use Case for Online Purchase... just tod. itself i need...

0 Answers  


what will be testcases for job portal such as naukri.com , monster.com (as existing user)

2 Answers   Unilog,


write test case for white board marker.

5 Answers   Adobe,


Categories