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






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

What all comes under test case review?

5 Answers   TCS,


pls send me the testcases for telecom billing system

0 Answers   Wipro,


We r developing one Web Site for construction company. In that Web site we have different option like About Us,Contact Us,Home,Sites,Site Map,Search Etc........ and front page of that web application contains 6 different pictures means single page contain 6 pics etc... write Test plan ,Test Scenarios,Test Case ....Plz answer this question ASAP

2 Answers  


How to execute test cases written in excelsheet???

8 Answers   TCS, Wipro, Value Labs, VFS,


write a test case for student admission form

2 Answers  


Writing Test cases based on the understanding of the UX document

1 Answers   Johnson Controls,


can you tell me how to write test cases for payments, receipts, inward clearing, outward clearing, A/c statements ?

0 Answers   HP, QSpiders,


Write the 3 TestCases to prove tht it is a softdrinkbottle or not.

9 Answers   Minecode,


write the testcases for a triangle ABC. given length of 3 sides of a possible triangle, check whether 3 sides do indeed form a triangle or not if they do then state whether the triangle is scalene, isoceles or equilateral. Note that the sum of any two sides of a triangle should be greater than third side. A+B>C B+C>A A+C>B. need urgently. thank u... by priya

6 Answers   Stag Computers,


is test case required to be baselined?

0 Answers  


write a test cases for table,pen,electric bulb?

6 Answers  


Could anyone please let me know what are the test cases for a rule based system? WE have a module on RBS which relates the data gathered to a set of rules and uses them to verify if the details are correct. Also we have a data acquisition module which collects the configuration details of a node entering a cluster using the CPUID. Can you please suggest test cases for these two modules, please?

0 Answers  




Categories