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.

how to write the test case for time and date like TIME : 09:34:32AM DATE : 12 MAY 1987

8 Answers   AmSol,

---

Write test cases on for windows media player?

1 Answers   CGI, COG, QMCPL,

---

For how many days (or) weeks you will test a product or software?

1 Answers  

---

I need GUI test case for home page?

0 Answers   Wipro,

---

is test cases are necessary for testing non functional testing

1 Answers   MSCI,

---

---

How can we write a good test case?

0 Answers  

---

How to write the test cases for STP

0 Answers  

---

Explain the static testing?

0 Answers  

---

Give me 10 test cases on library management system

8 Answers  

---

How many test cases can u write 1) File - open dialog box in notepad pleasse write

5 Answers  

---

If there are 3 modules what would be test for that three modules but that 3 modules are not developed or what are the test case for that 3 modules

0 Answers  

---

2.6.3 User Interface Different Polls could be present at different channels, pages within channels, and at home page. User interface for Poll will be as described below: - Beneath poll current result(running status) to be shown in graphical form(say progressing bar chart) all the time, in same window as poll. - Link ""All Polls >>"" to take user to Polls home page which will have all the active polls with results underneath. - All the polls not older than one month will come under Active polls category. - User can take Active open polls, but cannot react to Active closed polls. Can only view results of active closed polls. - No Interactives available for polls - "Add a comment", "Rate" - Registered User can take a poll only once, after that only result is shown to user. To unregistered user it will be open. 2.6.4 Interfacing/Sourcing Details - Polls is going to be a separate module, an internal application, which editor/admin can publish. - Admin/Editor should be able to publish polls on separate channels, pages. Assign closure dates. - Admin/Editor can upload images, change look n feel, add a brand, link/url to it. - System to capture user details(screen name/name, id, email id), do loyalilty points calculation and add to user loyality points. 2.6.5 Rules and Conditions Unless assigned a closure date, by default all Polls will be open for 30 days. this is the SRS how to write the test cases for the above functionalities help me

1 Answers   GE,

---