How To Test Banking Domain Applications: A Complete BFSI Testing

Guide
Last Updated:April 16, 2020
A Complete Guide to Testing Banking Application: BFSI (Banking, Financial Services, and Insurance) Testing
Process and Tips
Banking applications are one of the most complex applications in today’s software development and testing industry.

What makes Banking applications so complex? What approach should be followed to test the complex workflows
involved in banking applications?
In this article, we will be highlighting different stages and techniques involved in testing Banking applications.

What You Will Learn: [hide]

 How To Test Banking Applications?
 Importance Of Testing Banking Application
 Banking App Testing Workflow
o #1) Requirement Gathering
o #2) Requirement Review
o #3) Business Scenario Preparations
o #4) Functional Testing
o #5) Database Testing
o #6) Security Testing
o Other Stages In Testing BFSI App
 Integration testing
 Usability Testing
 Performance Testing
 User Acceptance Testing
 Sample Test Cases For Banking Application
 Conclusion
o Recommended Reading

How To Test Banking Applications?

Various Functions performed by Banking Applications are:

Let's first understand the characteristics of a Banking Application:

 Multi-tier functionality to support thousands of concurrent user sessions
 Large-scale Integration: Typically, a banking application integrates with numerous other applications such as
Bill Pay utility and Trading Accounts
 Complex Business workflows
 Real-Time and Batch processing
 The high rate of Transactions per seconds
 Secure Transactions
 Robust Reporting section to keep track of day to day transactions
 Strong Auditing to troubleshoot customer issues
 Massive storage system
 Disaster / Recovery Management.
The above listed ten points are the most important characteristics of a Banking application.
Banking applications have multiple tiers involved in performing an operation.

For Example, a Banking application may have:

 Web Server to interact with end-users via Browser
 Middle Tier to validate the input and output for the webserver
 DataBase to store data and procedures
 Transaction Processor which could be a large capacity Mainframe or any other Legacy system to carry out
Trillions of transactions per second.
If we talk about testing banking applications, it requires an End to End Testing methodology involving multiple
Software Testing techniques to ensure:
 Total coverage of all banking workflows and Business Requirements
 The functional aspect of the application
 The security aspect of the application
 Data Integrity
 Concurrency
 User Experience
What makes Banking applications so complex?
 Banking software mainly deals with confidential financial data so the performance of software should be
error-free and secure.
  Developers prefer a complicated design to develop these applications to ensure the application runs in a
desired secure manner.
 Banking is a constantly changing world. Banking, today, is made available to the customer using different
channels like brick & mortar branches, ATMs, online banking and customer care.
 With the advent of technology, many wallets have flooded the markets which connect to the banking
systems for financial transactions.
 Banking is also expected to be up and running 24 X 7 with high performance. Software upgrades, instant
fixes, etc. cannot be allowed to impact this availability.
 The banking world is also highly impacted by the constant changes brought in by the government in the form
of banking regulations. Any changes in the tax structure impact the banking system as well.
 The banking system also needs to up-to-date as far as new technologies are concerned. Data analytics like
Big Data Processing and getting instincts out of big data using Data Science is growing traction in the
banking world.
Above mentioned points make the banking system complex for developers to create a software application around it.

Importance Of Testing Banking Application

 Testing the Banking application assures that all the activities are not only executed well but also remain
protected and secured.
 Banking software is complicated with thousands of dependencies, the testing process requires more time,
resources, and continuous monitoring.
 As finances are involved here guidelines have to be followed strictly. Both testers and developers should
have good domain knowledge.
 Most importantly, it has to be ensured that the laws and regulations are enforced correctly in financial
transactions. This can only be ensured with testing.
 It’s also important to ensure that the application and the infrastructure on which the application has been
deployed is able to handle the load, especially during peak business hours, without causing any disruption.
This can be ensured by performing performance testing.
 In today's digital world, the one thing that concerns everyone is that of security. The banking applications
and the financial transactions that are performed within it needs to be secure from any attempt to break-in.
This can be ensured by performing security testing. Security testing helps enforce industry standards to
secure financial transactions.
 It’s also important to ensure that different modules of a banking application and integrated properly and
achieve the objective of the client. System Integration Testing helps achieve this task.
Banking App Testing Workflow
Typical stages involved in testing Banking Applications are shown in the below workflow. We will be discussing
each stage individually.
This is a Waterfall model of testing an application.
#1) Requirement Gathering
Requirement Gathering phase involves the documentation of requirements either as Functional Specifications or as
Use Cases. Requirements are gathered as per customer needs and documented by Banking Experts or Business
Analyst.

Experts are involved in writing requirements on more than one subject as banking itself has multiple sub-domains and
one full-fledged banking application will be the integration of all these domains.

For Example, A banking application may have separate modules for Transfers, Credit Cards, Reports, Loan
Accounts, Bill Payments, Trading Etc.
#2) Requirement Review
The deliverable of Requirement Gathering is reviewed by all the stakeholders such as QA Engineers, Development
leads and Peer Business Analysts.
They cross-check that neither existing business workflow nor new workflows are violated. All the requirements are
verified and validated. Follow up actions and requirement document revisions are done based on the same.

#3) Business Scenario Preparations

In this stage, QA Engineers derive Business Scenarios from the requirement documents (Functions Specs or Use
Cases); Business Scenarios are derived in such a way that all Business Requirements are covered. Business
Scenarios are high-level scenarios without any detailed steps.

Further, these Business Scenarios are reviewed by Business Analysts to ensure all of the Business Requirements
are met. It is easier for BAs to review high-level scenarios rather than reviewing low-level detailed Test
Cases.
For example, a customer opening a Fixed deposit on the digital banking interface can be a business scenario.
Similarly, we can have different business scenarios related to net banking account creation, online deposits, online
transfers, etc.
#4) Functional Testing
In this stage, functional testing is performed and the usual software testing activities are performed such as:

Test Case Preparation: In this stage Test Cases are derived from Business Scenarios, one Business Scenario leads
to several positive test cases and negative test cases. Generally, tools used during this stage are Microsoft Excel,
Test Director or Quality Center.
Test Case Review: Reviews by peer QA Engineers
Test Case Execution: Test Case Execution could be either manual or automatic involving tools like QC, QTP, etc.
The functional testing of a banking application is quite different from ordinary software testing. Since these
applications operate with customer’s money and sensitive financial data, they are required to be tested thoroughly.
No important business scenario should be left to be covered.

Also, the QA resource who is testing the application should have the basic knowledge of the banking domain.

#5) Database Testing

Banking Application involves complex transaction which is performed both at UI level and Database level, Therefore,
Database testing is as important as functional testing. The database is complicated & an entirely separate layer in the
application and thus its testing is carried out by database specialists. It uses techniques like:

 Data loading
 Database Migration
 Testing DB Schema and Datatypes
 Rules Testing
 Testing Stored Procedures and Functions
 Testing Triggers
 Data Integrity
The major purpose of database testing is to ensure that:
 The Application is able to store and retrieve data from the database without any loss of data.
 Completed transactions should be committed and aborted transactions are reverted back to avoid any
mismatch in data stored.
  Only authorized applications and users are allowed to access the database and the underlying tables.
There are primarily three ways of Database Testing:
 Structural Testing
 Functional Testing
 Non-Functional Testing
Structural Testing
It involves testing the database objects like databases, schema, tables, views, triggers, access controls, etc. Ensuring
that data types in tables are in sync with the corresponding variables in the application. Validating data and referential
integrity in the tables.

For Example, An amount field in the application should have a data type of decimal/float in the table.
– In order to comply with standards, users should be given access controls through views.

Functional Testing
It involves testing the databases that satisfy user requirements. There are two ways to achieve: Black box testing and
White box testing.

For Example, When we do an online money transfer, the sender account should be debited and the receiver account
should be credited with the exact same amount. If the transaction fails then whole transactions should be reverted
and the sender account should not be debited or credited back.
Non-Functional Testing
It involves load & stress testing and performance optimization. Load testing helps in identifying the most number of
transactions that can be performed concurrently without impacting database performance.

For Example,  Based on the input from load and stress testing banking applications can decide to add more
resources to their application during peak business hours and reduce the resources during off business hours. This
helps the bank to make optimum use of resources and save money.
#6) Security Testing
Security Testing is usually the last stage in the testing cycle. A prerequisite to commencing security testing is the
completion of functional and non-functional testing. Security testing is one of the major stages in the entire
Application testing cycle as this stage ensures that application complies with Federal and Industry standards.

Due to the nature of the data they carry, banking apps are very sensitive and are a prime target for hackers &
fraudulent activities. Security testing makes sure that the application does not have any such web vulnerability that
can expose sensitive data to an intruder or an attacker. It also assures that the application complies with standards
like OWASP.

In this stage, the major task is the whole application scan which is carried out using tools like IBM AppScan or HP
WebInspect (these are the most popular tools).
Once the scan is completed, the Scan Report is published. Over this report, False Positives are filtered out and the
rest of the vulnerabilities are reported to the Development team so that they start fixing the issues depending on the
severity of each issue.

Penetration testing is also done at this step to reveal the propagation of errors. Rigorous security testing should be
done across platforms, networks, and OS.

Some Other Manual tools for Security Testing used are Paros Proxy, Http Watch, Burp Suite, and Fortify.
The main purpose of security testing is to pinpoint any vulnerabilities the software application, may have.

The security testing tests the application against:

 Any external attack or attempt to hack the application with malicious intent.
 Any loophole in the software application could be exploited causing data or monetary loss.
 Any vulnerability in the network, servers, and workstations that hosts the application.
Following are the various types of security testing:
Vulnerability Testing: An automated program is developed and executed to check for various vulnerabilities.
Security Scanning: This variant revolves around investigating network and system vulnerabilities, provide solutions
to reduce the associated risk.
Penetration Testing: This variant of security testing imitates a hacking attempt to capture vulnerabilities and
loopholes, which otherwise could have gained access to the database or the application data.
Security Auditing: It involves auditing of the application and the associated networks for any security lapses.
Risk Assessment: This variant does an analysis to assess the level of risk, in an event when a vulnerability or
loophole is exploited for malicious intent. Such risk could be categorized in to low, medium and high. Based on the
level of risk, proper measures are advised by the testing team to reduce or avert the risk.
Ethical Hacking: This is performed by an organization on its systems to identify loopholes that could be exploited in
its application or network. The intent of this kind of hacking is not to steal or cause damage to the application or
network.
Posture Assessment: This is an umbrella assessment comprises of security scanning, risk assessments, and
ethical hacking.
SQL Injection: SQL Injection could be used to gain access to the server database. The testing is done to ensure that
the code is working correctly, which execute queries on the database based on following inputs from user:
 Brackets
 Apostrophes
 Commas
 Quotation Marks
Other Stages In Testing BFSI App
Apart from the above main stages, there might be different stages involved such as Integration Testing, Usability
testing, User acceptance testing, and Performance Testing.

Let us talk in brief about these stages as well:

Integration testing
As you know that in a banking application, there might be several different modules like transfers, bill payments,
deposits, etc. And thus, there are a lot of components developed. In integration testing, all the components and
integrated together and validated.

Usability Testing

A banking application serves a wide variety of customers. Some of these customers might lack the skills and
awareness required to perform the banking tasks over the app.

Thus, the banking application should be tested for simple and efficient design to make it usable across different
groups of customers. The simpler & easy to use interface is, the higher number of customers will be benefited from
the banking application.

It’s about examining the level of ease, business users or bank customers have in using the application. This testing is
not performed by the developer or tester but is performed by the business users.

For Example,  Nowadays everyone uses mobile apps. The banking app should be user-friendly and easy to
understand and use by the end-user.
Types Of Usability Testing
Comparative Usability Testing: This is comparison-based testing, where ease of usability of one website or
application with another. The target for such testing is to provide the best user experience.
Explorative Usability Testing: The aim of this testing is to identify what features should the new application or
software should possess in order to meet the bank’s customer requirements.
Following are advantages and disadvantages of Usability Testing
Advantages:
 The end-users of the application are usually involved with the testing, hence first-hand feedback is obtained.
 Rather than spending time on analysis and discussion about a feature that a product should have or not, it is
better to get the inputs from the end-user directly.
 We can catch any potential issues beforehand.
Disadvantages:
 As multiple end-users are involved in testing, their opinions if not precise can affect the requirement.
 The feed from end-users may get influenced.
Performance Testing
Certain periods of time like payday, end of the financial year, festive seasons might bring in change or spike in the
usual traffic on the app. Hence, thorough performance testing should be done so that customers don’t get affected by
performance failures.

A significant example from the past where bank customers got personally affected due to performance failures is
NatWest and RBS cyber Monday IT outage in which the customers had their debit and credit card got declined
transactions across shops in the country.

User Acceptance Testing

This is done by involving the end-users to ensure that the application complies with the real-world scenarios and will
be accepted by users if it goes live.

In today’s scenario majority of Banking Projects are using: Agile/Scrum, RUP, and Continuous Integration
methodologies, and Tools packages like Microsoft’s VSTS and Rational Tools.
As we mentioned about RUP above, RUP stands for Rational Unified Process, which is an iterative software
development methodology introduced by IBM which comprises of four phases in which development and testing
activities are carried out.

Four phases are

i) Inception
ii) Collaboration
iii) Construction and
iv) Transition
RUP widely involves IBM Rational tools.

Sample Test Cases For Banking Application

Test cases for New Branch
 Create a new branch with valid and invalid test data.
 Create a new branch without data.
 Create a new branch with existing branch data.
 Verify the reset and cancel options.
 Update branch details with valid and invalid test data.
 Update branch details with existing branch test data.
 Verify if the new branch can be saved.
 Verify the cancel option is working.
 Verify the branch deletion with and without dependencies.
 Verify if the branch search option is working.

Test Cases for New Role

 Create a new role with valid and invalid test data.
 Create a new role without data.
 Verify a new role can be created with existing test data.
 Verify the role description and role types.
 Verify the cancel and reset option is working.
  Verify the role deletion process with and without dependency.
 Verify the links in the role details page.
 Verify the admin login without test data.
 Verify all home links for the admin role.
 Verify the admin can change the password with valid and invalid test data.
 Verify the admin log out successfully.

Test cases for Customer and Banker

 Verify if all visitor and customer links are working properly.
 Verify the customer login with valid and invalid test data.
 Verify the customer login without any data.
 Verify the banker login without any data.
 Verify the banker login with valid or invalid test data.
 Verify the customer or banker can log out successfully.

Test cases for New users

 Verify if the new user can be created with valid and invalid test data.
 Create a new user with existing branch test data
 Verify if the cancel and reset option is working properly.
 Update user details with valid and invalid test data.
 Verify the deletion of the new user.
 check if the new user can be verified.
 Verify mandatory input parameters.
 Verify optional input parameters.
 Verify if a user can be created without optional parameters.

Test cases for the creation of a New Account

 Create a new account with valid and invalid user data.
 Verify if user details can be updated.
 Verify if a new user can be saved.
 Create a new account with the existing user's data.
 Verify the user can deposit the amount in the newly created account (and update the balance).
 Verify the user can withdraw an amount from the new account (after deposit and update the balance).
 In the case of salary, account verify the company name and other details are provided by the user.
 Verify if the primary account number is provided in case of a secondary account.
 Verify user details provided in cases of the current account.
 Verify the provided proofs for joint account in case of a joint account.
 Verify whether able to maintain zero balance in salary account.
 Verify whether able to maintain zero balance or minimum balance for the non-salary account.
 Verify the new user can log out successfully.

Test Cases For Net Banking Application

 Check if the user is able to open the bank site.
 Check if all the links on the site are working.
 Verify if the user is able to create a new account.
 Check if the user is able to login with valid and invalid username and password.
 Verify if either of the username or password is blank while login, the user should not be allowed to login and
an alert message is shown.
 Check if the user is allowed to change the password.
 If an invalid user or password is entered proper error message is shown.
 Users with an invalid password should not be allowed to log in.
 Verify that after repeated attempts to log in with an incorrect password, the user should be shown an error
message and blocked.
 Check if the user is able to perform some basic transactions.
 Verify that the user is able to add a beneficiary with valid and invalid details.
 Verify if the user can delete the beneficiary.
 Verify that the user is able to make transactions to the newly added beneficiary.
 After transaction verify if the accounts of both user and beneficiary are updated.
 Check if the user is able to enter the amount in decimal number.
  Verify if the user is not able to enter negative numbers in the amount field.
 Verify if the user is allowed to do transactions with or without minimum balance.
 Verify if the user can do a new RD.
 Verify that proper message is shown in case of transaction done with insufficient balance.
 Check if the user is asked for confirmation before any transaction is done.
 Verify if acknowledgment receipt is provided on each successful transaction.
 Verify if the user is able to transfer money to multiple accounts.
 verify if the user can cancel the transaction.
 Verify that account details reflect financial transactions done also.
 Verify that the time-out feature is implemented.
 verify that in case of session time out a user should log in again.
 verify that proper session time out is done in case any inactivity.
 verify that while doing transaction user is taken to secure mode.
 Verify if the user can log out successfully.
 Verify search and reset options.

How To Test Health Care Application – Part 1

Last Updated:April 16, 2020

Understanding Health Care Domain and Testing Health Care Applications:

Today’s article is going to be all about healthcare- domain/business information, components, what to test and how to
test.

This two-part article series is useful for anyone who wants to explore and enter into a different domain for testing,
learn and understand healthcare application workflow and testing process.
In short, this article will be your first step and a guide on your healthcare knowledge quest.  In part-2 we will
provide test scenarios for different applications under the Healthcare domain.
 To excel in testing, domain knowledge is the key. So, we are going to learn about the client’s business flow now.
What You Will Learn: [hide]
 Healthcare Domain- An Introduction
o How To Test a Healthcare Application?
o Health Care Application Testing Workflow
o Recommended Reading
Healthcare Domain- An Introduction
Health Care or Health Insurance is similar to general insurance. As you know, in any insurance, the insurer
(Insurance company) will provide the plans and the customer (Subscriber or Policyholder) will buy the policy of his
desired plan. The insurer will receive the premium amount from the policyholders and the policy Holders will get
reimbursements from the insurer for the valid claims they have submitted.

The same happens in healthcare insurance but in addition to insurer and policyholder, there are other major
contributors such as provider, TPA (Third Party Administrator), broker, etc.

We will now see each of the major contributors in detail:

#1) Insurer: An entity that creates a plan, sells the policy and reimburses policyholder or provider for the submitted
valid claims.
#2) Policy Holder: A person or an entity, who buys the policy from the insurer or broker, pays a premium to the
insurer and sometimes submits a claim.
#3) Provider: A person or an entity, which provides the healthcare service to the policyholder and their dependents,
either receive payment for the service from the policyholder or the insurer by submitting a claim.
#4) TPA: A person or an entity that manages the claims of the policyholder or provider and receives payment for the
management from the respective contributor.
#5) Broker: As you have guessed, he is an agent who sells the policy to the customers on behalf of the insurer and
receives a commission in return from the Insurer.

For Example, We can understand the basic function of contributors from the below example.
Mr. Enosh bought a health care policy that covers general physician consultation and vision problems from Mr.
Ponnar and pays a premium for the same to a healthcare company.

Once Mr. Enosh was sick and consulted the Physician Mr. Sabari for recovery, Sabari provided a prescription to
Enosh and submits a claim for the consultation to HealthCorp Company and receives the reimbursement. Mr. Ponnar
receives a commission from HealthCorp Company for the payment of premium by Mr. Enosh.

In the above example, ‘General Physician Consultation' and ‘Vision Problems' are the benefits of the health plan, Mr.
Enosh is the policyholder, Mr. Ponnar is the broker, HealthCorp Company is the insurer and Mr. Sabari is the
provider.

To clearly understand the difference between policy and plan, think plan as a class and policy as an object ( an
instance of the class). A policy can be categorized as individual policy and group policy based on the type of
beneficiaries it covers.

Individual Policy: An individual will be the policyholder; both the individual and his/her dependents will enjoy the
benefits of the health plan. Here the individual pays the premium.
Group Policy: An entity (Generally an employer) will be the policyholder, the members (Employees) of the entity and
their dependents will enjoy the benefits of the health plan. Here the entity pays the premium.
For Example, An example to have a clear idea of group policy is as follows,
MotoCorp Company buys a policy from HealthCorp Company for its employees and their family. Their claims are
managed by EasyClaim Company. Here MotoCorp Company is the policyholder, HealthCorp Company is the Insurer
and EasyCliam Company is the TPA.
How To Test a Healthcare Application?
Before testing an application, we should be aware of the healthcare industry workflow. The previous topic just gives
an introduction to managed health care, more details are available here.
An Insurer needs different applications to manage the following:
 Provider data
 Member data
 Premium billing/payment
 Broker data
 Claims entry/validation
 Broker commission calculation/payment
Generally, a Healthcare application will have the following list of systems:
 Member system: To maintain policyholder data, various plans with their list of benefits and generate
premium bills for the policyholder based on their plans
 Provider system: To maintain provider data
 Broker system: To maintain broker data and calculate commissions
 Claims system: For claim entry and validation
 Finance system: To do the necessary payment to provider/member/broker
 Member portal: To display the policyholder information, make premium payments and raise a request for
change information for policyholders
 Provider portal: To display provider information and raise a request for change information for providers
 Broker portal: to display broker information and raise a request for change information for brokers
This might not be an exhaustive list. But, this is the list to the best of my knowledge. Also, all applications might not
even be used. Sometimes, few of these applications are merged to make another combination application- other
times, these are stand-alone systems.

For Example, the Provider system can be part of the Member system in some healthcare applications. By Healthcare
application, I mean a set of systems maintained by an Insurer to facilitate their customers and partners.
Health Care Application Testing Workflow
The unique feature of the Health Care system is that these applications cannot be tested in any order we like. There
is a certain workflow to be followed:

 For a member/policyholder to be enrolled in a health plan he/she needs to be assigned to a provider

(Primary Care Physician) or a provider network, so there should be a way for the member system to validate
the assigned provider. Either member system connects to the provider system or a data feed should
periodically send to member system from provider system. Therefore the provider system should be tested
and ready to use before testing the member system.
 A claim should consist of provider ID and member ID in addition to other details. The claim system should
validate both the member and provider to validate the claim, so both member and provider system should be
tested and ready to use before testing the claims system.
 The finance system needs to have data from a member, provider, claim and broker system to write checks
or make EFT payments to the respective person or entity.
 Provider and broker systems are stand-alone.
 Portals should be tested at last since it needs data from the other applications.

Now, that’s the order in which the systems in Healthcare application should be tested.

Testing Healthcare Applications – Tips And Important Test Scenarios

(Part 2)
Last Updated:April 16, 2020

In the last article, we did some heavy lifting in terms of understanding the healthcare domain. We are ready to put our
“Tester’s hat” back on and now try to understand how to test the health care applications.

=> If you haven't read part 1 please read it here: How to Test Health care application – Introduction
We are now going to pick each application/system and come up with conditions that we are going to validate in each
one of them.

This article is useful for the testers who are already in the Healthcare domain or those who want to enter in
this hottest career field.
 Let’s get started!

What You Will Learn: [hide]

 Healthcare Application Testing – The Sample Test Scenarios
o Testing Of Provider System
o Testing Of Broker System
o Testing Of Member System
o Testing Of Claims System
o Testing Of Finance System
o Testing Of Member Portal
o Testing Of Provider Portal
o Testing Of Broker Portal
o Important Tips For Testing Healthcare Software
o Conclusion
o Recommended Reading
Healthcare Application Testing – The Sample Test Scenarios
This is the Sample Test Scenarios for:

Testing Of Provider System

#1) Provider System should be let us enter, edit and save provider data.
#2) Positive flow System testing: include scenarios to enter different types of Providers, change, save and inquire
about them.
#3) Negative flow System testing: include scenarios to
 Save a provider with incomplete data.
 Save a provider with a contract effective date less than the provider license date.
 Enter data of the provider which is already available in the system and save.
#4) System Integration testing should include scenarios to
 Validate the feed to downstream systems such as the feed to Member system, Provider portal, Claim
system, and Finance system.
 Validate if the changes from the Provider portal are incorporated in the respective provider record.
Testing Of Broker System
#1) Broker System should be capable of the following:
 Enter, edit and save broker data.
 Calculate the broker commission based on the premium payment details from the member system.
#2) Positive flow System Testing should include scenarios to
  Enter, edit and save broker record for different types of the broker.
 Calculate the commission for the active broker by creating a feed file with the respective record for members
with a different plan.
#3) Negative flow System Testing should include scenarios to
 Enter a broker record with insufficient data and save for different types of the broker.
 Calculate the commission for the terminated broker by creating a feed file with the respective record for
members with a different plan
 Calculate the commission for the invalid broker by creating a feed file with the respective record for
members with a different plan
#4) System Testing should include scenarios to
 Validate the feeds to the downstream systems such as the Broker portal, Finance system, and Member
system.
 Validate if the changes from the Broker portal are incorporated in the respective broker record.
Testing Of Member System
Member System should be capable of the following:
1. Enroll, terminate, reinstate and re-enroll a member
2. Add and remove a dependent
3. Generate premium bill
4. Process premium payments
Enrollment: In an Individual Policy, a policyholder is added under a plan with an effective date from which he/she will
be paying a premium for the benefits provided by the insurer and from which he/she is eligible for submitting claims
and receiving coverage.
In Group Policy, a member is added to the group (which is already added under a plan) with an effective date of
which he/she is eligible for submitting claims and receiving coverage.

Termination: In an Individual Policy, the policy is terminated with a termination date of which a policyholder will not
be covered by the insurance plan.
In Group Policy, either the member alone can be terminated with a termination date or the whole group can be
terminated.

Reinstatement: If a terminated member asks for the policy to be active again and the current date is within the grace
period from the termination date then the member can be reinstated without a gap in coverage. The policy effective
date will be the same old effective date and not the current date.
Re-enrollment: If a terminated member asks for the policy to be active again and the current date is beyond the
grace period from the termination date then the member can be re-enrolled with a gap in coverage. The policy
effective date will be the current/future date and not be the same old effective date.
For Example, A member is enrolled in a policy with an effective date as 1/1/2013 and terminated on 12/31/2013. lets
us take 30 days as the grace period fixed by the insurance company.
Case 1: If the member comes back on 1/15/2014 and wants the policy to be effective against then it
is  Reinstatement  if the member pays the premium for the period 12/31/2013 to 1/15/2014 then the policy effective
date will be the same old 1/1/2013.
Case 2: If the member comes back on 2/1/2014 and wants the policy to be effective again then it is Re-
enrollment  and the policy effective date will be 2/1/2014. Here there is a gap in coverage (1/1/2014 to 1/31/2014).
Positive flow System Testing should include scenarios to

 Enroll different types of members with past, current and future effective dates.
 Change and inquire about members.
 Generate a premium bill for an active member for next month.
 Terminate an active member with past, current and future termination date greater than the effective date.
 Re-enroll a terminated member with past, current and future effective dates.
 Reinstate a terminated member.
Negative flow System Testing should include scenarios to

 Enroll a member with insufficient data.

 Generate a premium bill for next month for a terminated member.
System Integration Testing should include scenarios to
  Validate the feed to downstream systems such as Member portal, Provider portal, Broker system, Claim
system, and Finance system.
 Validate if the changes from the Member portal are incorporated in the respective member record.
 Process the payment of a generated premium bill with the feed from the Member portal that has details of
payment made.
Testing Of Claims System
Claims in healthcare have diagnosis code and procedure code for the claim to be in detail.

 Diagnosis Code: Refers to the disease the patient had.

 Procedure Code: Refers to the treatment provided to the patient.
Claims System should be capable of the following:

 Enter, edit and process claims for the member as well as a dependent.
 Should throw errors for invalid claims based on the incorrect data entered.
Positive flow System Testing should include scenarios to enter, edit and process claims for the member as well as a
dependent.
Negative flow System Testing should include scenarios to
 Enter and validate a claim with invalid diagnosis code and procedure code.
 Enter and validate a claim with an inactive provider ID.
 Enter and validate a claim with a terminated member.
System Integration testing should include scenarios to validate the feed to downstream systems such as finance and
provider portal.

Testing Of Finance System

Finance System should be capable of writing paychecks and making EFT payments to the respective recipient by
processing the feeds from various upstream systems such as claims, member, provider, and broker system.

Positive flow System Testing should include scenarios to check whether the correct address or account number is
chosen for the respective provider, member or broker for the payment.
Negative flow System Testing should include scenarios to
 Check whether payment is done for the invalid member, provider or broker ID by creating respective records
in the feed.
 Check whether payment is done for the invalid amount (Zero or negative) for the member, provider or broker
by creating respective records in the feed.
System Integration Testing is not needed as this doesn’t have any downstream systems and the feeds from the
upstream are validated in the System Integration testing of respective systems.

Testing Of Member Portal

Member Portal should be capable of the following:

 View policy details and claim status.

 Make change requests in policy details.
 Make premium payments.
Positive flow System Testing should include scenarios to
 Log in and view policy details and claim status.
 Make change request to change address, name, phone number, etc.
 Make premium payments.
Negative flow System Testing should include scenarios to
 Log in with invalid credentials.
 Make payment for a paid premium bill.
 Make payment with an invalid check.
System Integration Testing is not needed as this doesn’t have any downstream systems and the feeds from the
upstream systems are validated in the system integration testing of respective systems.

Testing Of Provider Portal

Provider Portal should be capable of the following:

 View provider details, member details, and claim status.

 Make change requests in provider details.
Positive flow System Testing should include scenarios to
 Log in and view provider details, member details, and claim status.
 Make change request to change address, name, phone number, etc.
Negative flow System Testing should include scenarios to
 Login with invalid credentials
 View member details with an invalid member ID
System integration testing is not needed as this doesn’t have any downstream systems and the feeds from the
upstream system are validated in the system integration testing of respective systems.

Testing Of Broker Portal

Broker Portal should be capable of the following:

 View broker details and commission payment.

 Make change requests in broker details.
Positive flow System Testing should include scenarios to
 Log in and view broker details and commission payment.
 Make change request to change address, name, phone number, etc.
Negative flow System Testing should include scenarios to login with invalid credentials.
System Integration Testing is not needed as this doesn’t have any downstream systems and the feeds from the
upstream are validated in the System Integration Testing of respective systems.

That’s it- that’s all the modules and the aspects we would test in them.
Important Tips For Testing Healthcare Software
Tip#1) Dates are important and have to be accurate because a slight change in the date may cause a major defect to
be un-noticed.
Tip#2) In Healthcare, there are many test parameters such as different types of plan, members, providers, brokers,
commission calculation method, etc., – so care should be taken while designing test cases by having a track of
parameters covered and not covered.
Tip#3) Know the business users for the respective systems and think from their perspective to find any the best
defects.
Tip#4) It is not needed to follow the same order for system testing and the scenarios provided here just cover the
overall functionality of a healthcare application. You may also need to include some more scenarios (more hints
at this post) based on the requirements you receive.
Tip#5) Health care is now moving towards a cost-effective way of providing care. Thus they have introduced an
exchange model where the subscriber can have a view of plans given by all the insurers which increases the
competitive nature of the insurers thereby indirectly stating the need for cost reduction.
As healthcare evolves, there will be a need for the change in software being used and there comes the
revenue for IT by creation, modification, and testing of software applications involved- which means we can
anticipate more projects in this domain. So, keep a lookout, if this interests you.
Tip#6) The key to success in health care application testing is claims – the complete knowledge of them and how
they are adjudicated, etc.
Conclusion
Well, that covers the basics of the healthcare domain and a way to test healthcare applications.

Payment Gateway Testing: The Tester’s Hands-On Guide With

Checklist
Last Updated:April 16, 2020
 The Tester’s Guide to Payment Gateway Testing:
What are the payment processors?

As per Wikipedia, “A payment processor is a company (often a third party) appointed by a merchant to handle
transactions from various channels such as credit cards and debit cards for merchant acquiring banks. The payment
processor will both check the details received by forwarding them to the respective card’s issuing bank or card
association for verification, and also carry out a series of anti-fraud measures against the transaction.”
Some common Payment Gateways are Braintree, Authorize.net, PayPal, Bluepay, Citrus Payments etc. 
There is a lot of literature available online and offline about payment gateways and related terminology.

In this tutorial, I have tried to simplify some of that information and tried to add my experiences.

Recommended read => Testing Investment Banking Applications

During my first project, I was clueless about how to properly test a payment gateway. I learned gradually and worked
on successfully rolling out PayPal, Braintree and Authorize.net integrations with our eCommerce applications.
We will discuss common terminology, understand end to end transaction flow and useful tips and best practices.

What You Will Learn: [hide]

 Payment Gateway Terminology
 Difference between payment gateway and payment processors
 Transaction Flow
 Why do we need to test Payment Gateways?
 Kinds of Testing required
 Helpful Tips
 Payment Gateway Testing Checklist and Test Cases
 Setting up Sandbox: Braintree Payments Example
 Conclusion
 Recommended Reading
Payment Gateway Terminology
Let us discuss some terms that we will be using in this article:
1) Merchant – A merchant is a person or company that sells products or services. Flipkart, Amazon, eBay are some
examples of Merchants.
2) Credit Card – A plastic card that can be used to buy products or services through a credit account. It has a 16 digit
card number, an expiration date, hologram, magnetic strip, signature panel and a Card verification value (CVV)
number.
Front of Credit Card:

Back of credit card:

(Source: about.com)
3) Acquiring bank – Acquiring Bank is a financial institution that maintains the merchant’s bank account and enables
a merchant to accept and process debit and/or credit card transactions on their store.
4) Issuing Bank – Issuing Bank is the financial institution that issues the customer’s debit or credit card. Whenever a
customer uses a credit or debit card to make a purchase, the Issuing bank either approves or declines the transaction
based on the cardholder account standing and passes that information to the Acquiring Bank.
For example, the transaction will be rejected if the card’s expiry date is incorrect, or if the purchase amount is more
than the card credit limit, etc.
5) Transaction – The end to end process through which the merchant receives funds for a transaction with a
customer.
6) Authorization – Authorization is requested when a customer makes a purchase. This authorization is provided by
the customer’s issuing bank and confirms the card holder’s validity, the ability to pay, and the presence of sufficient
funds etc. Once this is completed, funds are hold and the balance is deducted from the customer’s credit limit but is
not yet transferred to the merchant account.
7) Capture – In this action, the merchant collects the relevant customer payment information and sends a
settlement/capture request to the processor. The processor uses this information to initiate funds transfer between
the customer’s card account and the merchant bank account.
Also read => Banking Application Testing
Difference between payment gateway and payment processors
There is a lot of literature available online about it and whether payment gateway and payment processor are distinct
modules with distinct functionalities.

During the course of my projects, I have observed that Payment Processor and Payment gateways are used
interchangeably without any actual distinction. The merchants usually refer the ‘Payment Gateways’ as payment
processors as these process all the payments.

The ‘Payment Processors’ consider themselves as Payment Gateways as they act as a means to process and
complete the secure payment transaction.
Transaction Flow
The following flow diagram summarizes the complete flow from the moment a customer places an order to the order
being successful or declined.

If a customer wishes to cancel the order, the following is the flow:

The difference between a void and return depends on whether a transaction is captured or not.

An unsettled payment can be voided, that means the held funds are credited back to the card holders account. If a
transaction is already settled or captured, then a refund is initiated which means the funds are taken from the
merchant account and credited back to the card holder’s account.

Why do we need to test Payment Gateways?

If we were to shop in an actual brick and mortar store, we would pay cash or swipe our card (credit or debit) through
the machine during checkout to complete the transaction.

If using credit or debit cards, the POS (Point of Sale testing) machine will indicate if the payment processing would be
approved or declined.
Similarly, during online transactions, we need to have a comparable system in place, which approves or disapproves
a transaction instantly.

From a customer perspective, the online payment processing on the e-Commerce website should be seamless.
Customer clicks ‘Pay now’ button and should see payment successful or declined message in next few seconds.

From the e-Commerce store perspective, the merchant needs to ensure that the complete payment cycle (getting
transactions from online store, capture and authorize, refund, voiding) are working fine.  If any of these
subcomponents do not work as expected, then it can be a problem for the merchant.

From the merchant perspective, the testing phase allows them to get used to the chosen payment processor flow and
evaluate if the chosen option is actually the best fit for their application and business.

Kinds of Testing required

Depending on the choice of the Payment processor and the product /application requirement, you may be required to
perform the following kinds of testing

 Functional Testing – Functional testing is required for newer, less established payment gateways to ensure
that the application behaves as it should i.e. it handles orders, calculations, taxes, etc. exactly how it is
supposed to. For more established payment processors, this kind of testing may not be required.
 Integration Testing – Integration testing is critical while integrating with a payment gateway. As a tester,
you would need to verify that the integration of your website/online store/application is working fine with the
chosen payment gateways. As a tester you need to verify the entire transaction flow:
 Place order
 Check if funds are received in merchant account
  Verify if transaction can be refunded or void successfully
 Performance Testing – It is essential to test the website/online store/application for performance. The
payment processor should not fail if multiple users are trying to complete transactions at the same time.
 Security Testing – During a transaction, a customer will be providing sensitive information like their credit
card number, CVV number etc. It is very important to ensure that all the sensitive information is transmitted
after encryption and that the channel is secure.
Helpful Tips
Based on my personal experience, the following are some helpful tips for testers:

#1) Research if a free sandbox environment (for trial and exploratory purposes) is available for the Payment gateway
that needs to be tested or implemented. Having a sandbox available is definitely helpful and gives the team that extra
flexibility to customize the tool and test as in depth as required.
#2) Make sure the transaction is tested end to end. In our projects, we tested and reported numerous bugs related to
data capture and data flow from application to the Payment gateway. Some of the specific bugs were:
 Customer (buyer) name information was not getting captured correctly
 The customer Credit card expiry date was getting captured incorrectly due to an incorrect function which
was causing the transactions to be declined by the issuing bank on account of incorrect credit card
information.
 Duplicate transaction showing in Payment Processor
#3) Research the limitations of the payment gateway sandboxes.
For example, Authorize.net sandbox supports one currency per sandbox, so if you need to test multiple currencies,
you will need to configure different sandboxes. Also with that, you would never be able to ‘truly’ test how the system
will behave when the Live Authorize.net account will process Multi-currency transactions.
#4) If payment fails during a transaction for any reason, a suitable message should be shown to the customer. Any
error message that is too technical like ‘Object not set to instance’ or ‘404 error’ can confuse the customer and impact
user experience.
It is also a good idea to display a generic message like ‘There seems to be some issue in processing the transaction,
please contact us at 1-800-800-8000’.

#5) For the purpose of post production release verification, the client (application business owner) would need to
create a live payment processor account, set up their Merchant ID etc.
Depending on the payment processor chosen, it may take anywhere from 2 days to few weeks to set up the account.
This should be communicated by the project manager to the client in advance with sufficient time to set up the live
account before the application and payment processor integration are go live.

Payment Gateway Testing Checklist and Test Cases

Like any other application, testing payment processors involves proper test planning.

The following checklist can be helpful for testers and could be used as a reference:
1) Set up payment processor sandbox.
2) Gather test credit card numbers that would be used for testing different credit cards. As an example, such
information for Braintree payment processor can be found at Braintree payments.
3) Verify the behavior of the application when a transaction is successful.
4) After successful transaction verify if the payment gateway returns to your application to show some kind of
successful transaction/confirmation message.
5) Verify that the customer gets some kind of transaction confirmation notification like Order confirmation email, etc. if
the transaction is successful.
6) Check what happens if a payment fails or payment processor stops responding- is there any error message?
7) Verify the application behavior with browser popup blocker on and off. This may be helpful if any confirmation
messages are being displayed in the popup.
8) Verify different fraud prevention/security settings.
For example, if customer billing information does not match with the address provided to issuing bank- any mismatch
will result in transaction decline.

9) Verify the transaction entries in the database if the tester has access to the Application database.
10) Check what happens when a customer session expires.
11) Check the console during entire transaction and report any console errors that are observed.
12) Verify that that transaction is done on a secure channel.
For example, the checkout pages may be HTTPS versus rest of website that are HTTP pages.

13) Verify that the payment processor currency is setup correctly.

For example, if the application/website is a Canadian company/retailer, the payment processor should be set up to
accept CAD currency.

14) If the applications have multiple payment options like Credit card and PayPal together, both payment options
need to individually tested from end to end.
15) Verify that refund or void amount (from payment processor admin portal) is same as the transaction amount. In
no case, the refund/void amount should exceed the transaction amount.
Read also => Testing Retail Banking System
Setting up Sandbox: Braintree Payments Example
1) Navigate to Braintree website.
2) Click on ‘Try the sandbox’ button.
(Note: Click on any image for an enlarged view)

3) You will be redirected to the Braintree sandbox website. Fill all the required information and sign up for the
sandbox

4) You will receive an email notification at the email address provided during sign up regarding confirmation of
account creation

5) You need to fill in the user information form to process further where you would be required to choose a password.
Click on ‘Agree and Create your account button’

6) You will be logged in and redirected to the Braintree Admin portal

7) Note the Sandbox keys and use them in your application to integrate with this Braintree sandbox.

8) After integration is done, the sandbox is ready for use. If you need to update the sandbox settings you can do so
using the settings menu.

Commonly used settings menu option:

Conclusion
The payment processor is a very important component for any e-Commerce application that is designed to accept
payments from its customers. Therefore it is essential to test this component thoroughly. Any missed scenario can
impact the sales /transactions of the seller and negatively impact the user experience for the customer or buyer.

Testers need to prepare or set up the test environment (sandboxes, gather dummy credit card information, response
codes etc.) and formulate a testing strategy- both for the Test environment and live/post production release testing.

8 Important Segments Of Testing ECommerce Websites

Last Updated:April 16, 2020

E-Commerce Testing – How to Test an eCommerce Website/Application

In today's world, I bet you won’t find anyone who hasn't shopped online. E-commerce/Retail is a business that thrives
on its online customers. Shopping in person vs. shopping online has many advantages. Convenience, time-saving
and easy access to products worldwide, etc.

A good E-commerce/Retail site is key to its success. It must be a worthy counterpart to the storefront. Because, when
you go shopping at a physical store, the customer has already made a commitment to visit and might give the brand
a chance. 
Online, choices are many. So, unless there is engagement from the beginning, the user might just leave.
 The better the site, the better the business.

Since so much lays on the application, it is critical that it undergoes thorough testing.

E-commerce application/sites are web applications or mobile application too. So, they undergo all the typical test
types.
 Functional Testing
 Usability Testing
 Security Testing
 Performance Testing
 Database Testing
 Mobile Application Testing
 A/B testing.
For a quick look at most often performed tests on a typical web application, check out:
=> 180+ Sample Test Cases for Testing Web and Desktop Applications
However, Retail sites are highly dynamic in nature. There are new offers, new products, new bestsellers, Sales, etc.
This means the site doesn’t stay the same for too long. Therefore, it could get overwhelming for many.

The trick is to divide and conquer.

Let’s see with examples how to test and eCommerce Site:
What You Will Learn: [hide]
 E-Commerce Testing Checklist
 #1) Homepage – Hero Image:
 #2) Search:
 #3) Product Details Page:
 #4) Shopping Cart:
 #5) Payments:
 #6) Categories/Featured Products/Related or Recommended products
 #7) After-Order tests
 #8) Other tests:
 Challenges Automating E-commerce Website
 Conclusion:
 Recommended Reading
E-Commerce Testing Checklist
Below, we have listed important segments and test cases for eCommerce website testing.

#1) Homepage – Hero Image:

Homepages of retail sites are busy. They have a lot going on. But almost all of them have a Hero Image:

This is the kind of the clickable image (a slideshow of sorts) that occupies the majority of the page.

The following are a few things to test:

 Is it going to auto scroll?
 If yes, at what interval will the image be refreshed?
 When the user hovers over it, is it still going to scroll to the next one?
 Can it be hovered on?
 Can it be clicked on?
 If yes, is it taking you to the right page and right deal?
 Is it loading along with the rest of the page or loads last in comparison to the other elements on the page?
 Can the rest of the content be viewed?
 Does it render the same way in different browsers and different screen resolutions?
#2) Search:
Search algorithms are very important for the success of a retail site because we can’t always place what the users
want to see right in front of their eyes.

Common tests are:

 Search based on Product name, brand name or something more broadly, the category. For
example Camera, Canon EOS 700D, electronics, etc.
 Search Results have to be relevant
 Different sort options have to be available- based on Brand, Price, and Reviews/ratings etc.
 How many results to display per page?
 For multi-page results, are there options to navigate to them
 Also, search happens in many places. Please take the search drilling down into multiple levels into
consideration when validating this functionality. For example: When I search on the home page, I might see
something like this:

When I navigate to categories and go to a sub-category, maybe movies, this is what I am going to see:

#3) Product Details Page:

Once a user finds a product either through search or by browsing or by clicking on it from the homepage, the user will
be taken to the product information page.

Check:
 Image or images of the product
 Price of the product
 Product specifications
 Reviews
 Check out options
 Delivery options
 Shipping information
 In stock/Out of stock
 Multiple color or variations options
 Breadcrumb navigation for the categories (highlighted in Red below). If navigation such as that is displayed,
make sure every element of it is functional.

#4) Shopping Cart:

This is the penultimate stage before the user commits to the purchase.

Test the following:

 Add items to the cart and continue shopping
 If the user adds the same item to the cart while continuing to shop, the item count in the shopping cart
should get incremented
 All items and their totals should be displayed in the cart
 Taxes as per location should be applied
 A user can add more items to the cart- total should reflect the same
 Update the contents added to the cart- total should reflect that too
 Remove items from the cart
 Proceed to checkout
 Calculate Shipping costs with different shipping options
 Apply coupons
 Don’t check out, close the site and come back later. The site should retain the items in the cart
#5) Payments:
  Check different payment options
 If allowing check out as Guest, simply finish the purchase and provide an option to register at the end
 Returning customers – Login to check out
 User sign up
 If storing customer Credit card or any other financial information, perform security testing around this to
make sure it is secure.(PCI compliance is a must)
 If the user is signed up for a long time, make sure the session is timed out or not. Every site has a different
threshold. For some, it is 10 minutes. For some, it might be different.
 Emails/Text confirmation with the order number generated
#6) Categories/Featured Products/Related or Recommended products
The most popular FAQ I get from E-commerce testers is: Do I have to test every category/every product?
The answer is NO.

If you are a returning customer you will be shown some recommended products on the home page or in your
shopping cart.

Featured products also change almost every day.

Since these are dynamic elements, the best way to test these parts of the application is to test the algorithm based on
which these sections are populated.

Check your Data mining/BI systems and check from the backend the queries that populate these sections.

#7) After-Order tests

Check:
 Change the Order
 Cancel the Order
 Track the Order
 Returns
#8) Other tests:
 Login
 FAQs
 Contact Us page
 Customer Service page etc.
Challenges Automating E-commerce Website
To remain on Safer Edge and deliver the desired results to the client you need to shift the focus on quality and
performance of your E-commerce website while shrinking timeline as much as possible

In general Automation Testing starts by selecting right test automation framework which directly impacts on the result
of the test automation project. The framework must include the test scripts and the scenarios of various automated
processes.

Based on the framework, the testers can easily execute the tests and obtain relevant results by generating test
reports. But selecting right tool to automate E-commerce Website depends on many key parameters.  It is always
important to compare the available tools based on key parameters like features, performance, extensibility, licensing
cost, maintenance cost, and Training and support.

You must take advantage of many open source test automation tools to automate more testing efforts without
investing additional funds.
#1) E-commerce websites are much entangled in nature, automating each action is not possible because we cannot
assume the nature of the customer.
#2) Continuous changes for e-commerce demands Regression so run regression test suit every day to keep track the
effects of change.
#3) Always go with Automating Integration type of scenarios that should cover from selecting a link on home page till
checkout and payment gateway page. Hereby, you can at least cover maximum user experience with E-commerce
Website, so that adequate testing can be achieved by automating regression cycle.
#4) Never waste time automating on the unstable application. A simple change will affect your whole test suits and
you have to recreate it.
#5) Homepage of E-commerce Website is very important and contents many information and 1000 of links
associated with each product and these links grow up every day as new offers or product is added to a page. So
before proceeding to regression testing its best to verify every link in page by using HTTP status code.
#6) When you are executing test scripts on a different browser at the same time. If a product is added to shopping
cart or removed that information should be reflected in other browsers too.
#7) When you running test parallel this will obviously fail your script in such scenario you have to periodically refresh
your page to retain cart information. In real time you may come across this scenario such as a user may sometimes
use mobile e-commerce app and also mobile e-commerce web application.
#8) Don’t neglect to verify each product details and pricing details whether it is 10 products or 1000 products it should
be as per the seller requirement. This is the phase where you can make or break a customer slight mistake will lead
to a big loss.
#9) Create yourself a lot of interrupted scenarios that usually user come across design your script very robust so that
your script afford it and still run and pass the script.
For Example, you stored all the card information and clicked on submit due to low charge or network issue
application stuck. In this case, a user is notified about his transaction status through email and message to phone you
should validate this email or message in a test script.
#10) Web element of E-commerce website keeps changing so always Create manual xpath. Some Web Elements
attributes will be same so there will be no unique way of distinguishing in such scenario use contains() method of
xpaths or scroll into view.
#11) Automate Accessibility Testing by keyboard actions without using mouse action you definitely will come across
some of the problems and fix it. This plays a significant role in user interface testing.
#12) Tester should be carefully designed the scenario and add initiate checkpoint and insert login script whenever it
is required.
#13) Maintain different scripts for a different mode of payment to avoid confusion. Check if what happens if an order
is canceling after payment.
#14) Performance testing in other hand plays a very crucial role. The factors you need to test here request per
second, Transaction Per minute, Execution per click, a Response time of page load, duration of the task, Length of
time between click and page display and DNS lookup.
#15) Security Testing is where customer trust is gained on which e-commerce is built so here you have to spend a lot
of time testing on DENIAL OF SERVICE ATTACK, User Account security, Data confidentiality, content security, credit
card security, disable non-essential services.SSL Certificate Validation.
#16) Automating  Localization testing is very challenging in e-commerce because of Compliance with accessibility
standards to support multi-lingual markets and business regions.
Conclusion:
Now, that we have a few tests listed out, let’s move on to a couple of finishing thoughts on eCommerce Testing.
A website should work – not just on computers but on mobile devices too. It needs to be responsive and secure. The
Database should be optimized and the ETL processes should help maintain a Data Warehouse that aids for OLAP
and BI. E-commerce testing should focus on all of that.
However, the most important part of E-Commerce Testing is whether the visitors are converting into paying
customers or not. The number of visits that are becoming the customer is called “Conversion Rate”.

So does one feature promote better conversion as opposed to another, is important testing. That is why A/B
testing and Usability Engineering for E-Commerce sites are gaining prominence.
Check out this article: The $300 Million Button
There are tools that are targeted at helping E-Commerce sites analyze their design for better conversion rates:

 Optimizely: A personal favorite. Very affordable and very insightful for E-Commerce A/B testing
 Unbounce: You can build your own landing pages and do a quick split or A/B testing
 Concept Feedback: You can submit your website and get expert feedback on your site’s design and
strategy.
Any usability testing tool can be used here, but the above three are my favorite.
 How To Test Point Of Sale (POS) System – Restaurant POS Testing
Example
Last Updated:April 16, 2020

What is Point of Sale (POS)?

POS alias Point of Sale is a place where transactions take place. You can see POS systems in Retail Stores,
Restaurants, Hospitals and almost everywhere these days where payments are involved.

Most of you may very well understand what a barcode reader is or a wireless payment device is (the most used
devices for payment transactions) but POS, in reality, involves a lot of components and each of the components
needs to be integrated well for it to run successfully. 
In today’s article, I am going to write about what makes POS testing different from others. I have also
incorporated testing tips throughout the article to make this helpful for our testing community.
 Example of Restaurant POS system testing included also

Let’s look at:

 What Makes POS Application Testing Different
 EPOS (Electronic Point Of Sale) Architecture
 EPOS Physical Components
 Levels/Functions of POS
 Example of Restaurant POS system testing included
Recommended reading => How to Test an eCommerce Application
What You Will Learn: [hide]
 What Makes POS Testing Different:
 POS Architecture:
 POS Physical Components and How to Test These:
 Levels/Functions of POS:
 Level #1) Application Level/Front Office Functions:
 Level #2) Back of House Functions
 Level #3) Corporate Level Functions
 Recommended Reading
What Makes POS Testing Different:
POS System Testing looks complex, but it is not that tricky for those who understand the concept well. It is interesting
because you get a feel of sitting in a store and executing your test cases since POS requires setup as you would see
in any stores.
This makes it different when compared to sitting in your cubicle and running some checks in a web app.
Organizations dealing with POS system testing maintain separate labs.

What are the challenges in POS testing?

 Multiple configurations as per the store requirement – I will explain with a simple example, say a retail chain
wants to run a promotional offer only in one particular city, in such case, special configurations are required
to be done for POS systems running in that city.
 POS requires a proper setup with all the devices, and also multiple types of hardware devices and versions
of the software.
 Multiple devices require compatibility testing and also a thorough integration testing
 PCI compliant, because POS  test deals with end user’s card details.
POS Architecture:
Each of the terminals in a store is connected to a file server. The settings or the main configurations get done on the
server and then pushed to each of the terminals in the store. The XML’s or batch jobs are used to do such updates.

For large retail stores or chain of stores, none of the changes are done locally. Since POS systems accept Card
payment, they are integrated with the third party providers who mainly do credit card processing, so whenever a
credit card transaction takes place, data is sent to the third party or banks for authorization.

(Click on image for enlarged view)

Image Source. 
POS Physical Components and How to Test These:
#1) Terminal – Terminal is the main screen which is used to enter the details of the transaction. These are mostly
touchscreen devices. All the configurations, be it related to Product List, Pricing, Promotional Offers, Payment Modes,
gets pushed to the terminal. This is the main device used at any POS.
 Terminal Testing requires validation to ensure that the devices are connected to the network and that the
latest OS is running on it to support the POS app.
#2) Display Pole – Display Pole is the device which displays the item price once the product is scanned using the
barcode scanner.
 Verify display pole displays the same price as seen on POS terminal
#3) Barcode Reader – Barcode Reader is used to scan the products. After the scan is complete, a check is done in
the backend to verify if the item exists in the inventory list and also retrieve item price. Once the item gets sold the
inventory is updated to reduce the available number of units.
 For Testing purpose, validation can be done by scanning a product missing from the inventory list
  Validate by scanning products which are available in the inventory list but with no price tagged
 Validate by scanning products which are available in the inventory list with proper tagging to a price level.
#4) Cash Register – Cash Register is used to storing Cash. For any cash transaction, the cash register opens
immediately for cashiers to accept the cash from the customer and also return the balance amount if any.
 Cash Register testing can be done by selecting payment mode as Cash, and doing cash transaction with a
refund amount.
#5) Handheld Device – Handheld devices are wireless devices which are used to accept credit card payments.
These make it easy to get user authentication by carrying the device to the end user directly, where users can enter
card pin.
 Testing can be done by creating a transaction by selecting a mode of payment as Card.
 Verification for the manual amount entry should be done.
#6) Printer – Printers are connected to each of the terminals and are called as register printers, these are used to
generate the receipt after each transaction.
 Testers can verify receipt printing, check for alignment, text overwrites, Text size, Fonts, etc.
 Error Handling Case can be verified, say what will happen if the print is given when the printer is not in a
ready state or the printer is out of paper.
 Verify the result when the printer goes offline or loses connection in the middle of the transaction.
#7) Magnetic Swipe Reader – MSRs are used to swipe cards used for payment which can be debit, credit or Gift
Cards. This is mostly used in retail stores or restaurants, but with changing times, where a user is required to key in
the PIN for payment, at many places you would see that a wireless device is used for accepting card payments.
 In the case of Gift Cards, MSR’s are used for balance check, expiry date and for payment. Printed receipts
are given to guests for authorization. Testers should validate these cases.
Also read => 7 Types of Software Errors That Every Tester Should Know
Levels/Functions of POS:
There are basically 3 levels or functions involved in POS.

Level #1) Application Level/Front Office Functions:

1) Sale Transaction – The main purpose of any POS system is facilitating transactions –
 Validating a successful Sale transaction which would include item scanning using either a barcode device or
manual entry using the keyboard, ensuring the total payable amount gets calculated and displayed on the
screen and it should end with a successful payment and receipt printing.
 Validating the correct tax amount calculation
2) Payment – Payment is yet another important area in scope for testers. This is due to the vast range of payment
modes accepted by POS.A POS allows payment through Card, Cash, Gift Cards. They also accept certain coupon
codes, discount vouchers.
 Cash Validation – Cash Validation is the simplest one to test. The system calculates the remaining balance
and makes cashier’s job easy to refund the amount to the customer. Many a times the users might prefer to
make partial payments- some by using Gift card (GC) and remaining by Cash. Testing should be done to
validate if the system accepts and allows partial payments.
 Card Validation – Payment through Card would always require a third party authorization. Card payment
starts by swiping the card – through MSR or a handheld device then taking customer’s authorization for the
specified amount. The same amount then gets authorized by third party banks.
 Gift Card Validation – Testers can validate the expiry date, an amount on the card before redemption can
be validated by swiping the card on the MSR, swipe it both ways to see system behaviour, validate in the
partial payment transaction, validate by overpaying using the card.
 Discounts/Coupons/Promotional Offers – This is a tricky testing area because the systems are designed
to accept a coupon code only and not all types of discounts, hence validation should consist of all types of
combinations. Testing can be done by using a code which works on total amount or using a discount
voucher applicable on certain items. Again, promotional offers are short-lived and aren’t applicable
 everywhere, hence testing for discount and coupons require a little care. Also, validate the order in which
discounts are applied. Sometimes, store discounts don’t work over manufacturer’s coupons and sometimes
they do. So, be extra careful when testing this.
Level #2) Back of House Functions
1) End of Day – End of Day is the most important activity done at the backend. During EOD, several reconciliations
are done and backend systems are updated.
Several summary reports, including the daily sales reconciliation, get generated and sent to stakeholders because
this gives an indication on how the day was in terms of sales. Also, a summary is sent to the banks for all the credit
card transactions done during the day. Inventory system gets updated to reflect correct stock balance.

This forms one of the major areas for test. Important scenarios which can be included as part of EOD testing can be:

 Verify that EOD process run is successful. This will have several intentional failures to ensure the
operational day is closed or not. Say in a restaurant, the managers will not be able to run EOD process if all
checks are not closed if all employees are not clocked out from the system. Testing should include running
this process including all checks with positive and negative scenarios. Usually, this is an automated process
which is scheduled to run at a certain time interval in real stores. For testing purpose, this process should be
tested manually.
 Verify Reconciliation Reports are generated and validate the contents of the report to ensure data on the
report matches to the data from that particular store. For such types of testing, tester’s can manually create
some transactions and keep a note of the data entered, and generate reconciliation report at the day end
and match the data they entered. Reconciliation report would be more like a balance sheet with the debit
and credit details.
2) Employee Scheduling – Another important BOH activity involves the scheduling function which mainly deals with
creating a work schedule for employees. Employees should clock into the system as per their schedule.
Scheduling can be done manually or using an automated way by using data from past sales patterns and project
labour requirement. The scheduling is a backend activity but the validation happens in the front end when the
employee tries to clock in.

 Validation should include verifying an unscheduled clock in

 Scheduled Late Clock in and clock out
 Scheduled early clock in and clock out
3) Inventory Management – Another important area is the inventory management. Store Managers mainly require
such systems to track products through each stage of the inventory cycle and also to have an idea before an item
falls below the stock level.
Hence, Inventory systems are designed so that managers can order right product at the right time, in the right
quantity from the right vendor and at the right price.

Test Validation should incorporate:

 Validation on quantity to be purchased

 Alerts if stock level goes below par
 Placing of order
 Validating the correct Item List with correct pricing is displayed on POS for selection
 Item and Price Association, Master level validation
Level #3) Corporate Level Functions
Corporate Level Functions doesn’t require you to sit in front of the POS system to do them but they are done using
any laptop/desktop with the app or software installed but they are in some or the other way integrated with the POS
systems. If corporate functions are done using a web application, there will be a mechanism that will push the
changes or settings to the POS.

1) HR and Payroll – HR and Payroll system deals with employee recruitment, maintaining employee salary/wages,
labour laws, Tax Details, Employee Availability and Employee Leave.
Mostly the payroll maintenance happens with a third party like ADP etc. hence the integration needs to be tested well.
The HR activities mostly are maintained in-house. Payroll becomes a separate huge area for testing as it requires all
sorts of calculations before an employee’s paycheck amount gets finalised. It forms a huge scope for testing.
  Validation could be done for HR activities like recruiting employees and then ensuring employees are
imported to POS systems
 Salary/Wage calculation as per labour laws
 Employees ability to enter leave details
2) Finance and Accounting – Finance and Accounting system is the one that requires the reporting. P&L
statements, planned budgets, variances, stores daily sales, etc. All these details are required by accounting team to
ensure whether the POS store is on track or not.
A lot of decisions are taken based on these report’s analysis. Say, if the team decides to open a new store, based on
historical data and analysis, the accounts team approves the budget and the area where the store could be opened.
Also, such details help them find the areas for improvement.

 Validate the generation of proper reports

 Verify the analysis logic
 Validation of the income statement and balance sheet
3) Vendor Management – For the supply of goods, any retail industry would require vendors, now evaluating the
right vendor who provides a reasonable pricing and to monitor their performance is all taken care by the vendor
management system.
From testing perspective, below important validations can be done:

 Validating entry and maintenance of Vendor detail in the system

 Validate vendor pricing
 Validate Vendor performance by tracking on- time delivery, quality of products delivered, etc.
4) DW and BI – Data Warehouse enables any industry to store and keep details on the transaction for years which
can be used to know the trends, formulate buying patterns, etc. Business Intelligence tools are used to retrieve this
huge amount of data from different systems and give the end user an opportunity for analysis.
DW systems get updated from the data that comes from the POS systems. Hence, from testing needs, this again is
critical for testing. Many organizations use BI tools or some develop in-house analytics. But in both cases, testing is
required.

DW and BI systems help people at the corporate level by simplifying report generation and customizing reports as per
their needs, it also helps a better performance tracking.

 Validation at POS level can be done for transactional data, but DW requires validating historical data
 Validate user’s report generation ability and customization using BI tool.
Conclusion:
I hope this article explained POS testing in detail. I have another detailed article on how POS system testing can be
done for the restaurant industry.

Telecom Domain Testing: Protocol Testing And Telecom Testing Tools

Last Updated:April 16, 2020

Basic knowledge of Telecom Domain for Testers: Learn Telecom Testing (Protocol Testing) with the
best Telecom Testing Tools 
Before moving deeply into Telecommunication (Telecom) domain, let us first understand what a Domain is and why
Domain Knowledge is important in the Software Industry?
In those days, testing done was only specific to an application and there was no much involvement of domain in it.
But nowadays, with the advancement in technology, demand, client expectation, etc., it is highly important to have the
specific domain knowledge to test a specific application.

What You Will Learn: [hide]

 Introduction
 Advantages of Having Domain Knowledge
o #1) Reduces Training Time
o #2) Productivity
o #3) Good understanding of User Interface & back-end processing
 o #4) Knowledge of Technical Terms of the domain
o #5) Understanding of Business Processes and Rules
o #6) An Asset to the Organization
 Overview of Telecom Domain
 Business Processes in Telecom Industry
o #1) Operations Support Systems (OSS):
o #2) Business Support Systems (BSS):
 Protocol Testing
o #1) Routed Protocols:
o #2) Routing Protocols:
 Types of Protocols
 Protocol Testing Process
 Sample Test Case for Protocol Testing
 Testing Types Performed on Telecom Software or Project
o #1) Conformance Testing:
o #2) IVR Testing:
o #3) Interconnection Testing:
o #4) Interoperability Testing:
o #5) Performance Testing:
o #6) Security Testing:
 Automation of Telecom Process
 Tools used during Telecom Testing Project
 Sample Test Case in Telecom testing
 Conclusion
 Recommended Reading
Introduction
Domain knowledge is much essential for a tester because testers having domain knowledge can test their respective
software applications better than the others who have little or no knowledge of the domain.

Domain means a specific industry like Banking, Insurance, Telecom etc. Usually while developing any project or a
software, domain knowledge is critical as the entire software is dependent on the business logic for that specific
industry.

Business logic is different for each industry, hence we require a domain expert who is a master of the subject and
knows the in-and-out of the project.

Advantages of Having Domain Knowledge

Domain knowledge is relatively important for testing any project.

The list given below shows the various advantages involved in having domain knowledge:
#1) Reduces Training Time
If a tester has domain knowledge then only minimal training is required for them and this, in turn, will save the cost
and time of the project.

#2) Productivity
Any organization having testers with domain knowledge will be productive as testers can understand any problem
specific to their domain expertise very easily and provide the exact solution to the problem by reducing the analysis
time.

This will increase the productivity of the project as well as the organization.

#3) Good understanding of User Interface & back-end processing

A tester with an intense knowledge of domain can suggest the user interface (UI) of an application from the end-user
point of view. Also, they can identify the defects at the early stage of testing with the help of their knowledge of back-
end system.
If a tester has domain knowledge then they can think out of the box and can write unique test cases which may raise
valid questions on the current workflow of an application.

#4) Knowledge of Technical Terms of the domain

Usually, a developer uses technical terms during a discussion, hence domain knowledge will be helpful for a tester
during such discussions. This will be an added advantage to the testing team as well.

If a tester has domain knowledge then they can review the test cases technically and suggest technical changes in
the test case flow as per the business requirement.

#5) Understanding of Business Processes and Rules

Testers with domain knowledge can participate in discussion with the business team and development team. Their
knowledge will play a vital role while representing an organization in front of the client. Such testers having a detailed
knowledge of the domain processes and rules can easily spot issues in the requirement document.

#6) An Asset to the Organization

Testers with domain knowledge can play the role of a trainer to the new joiners in the organization. This again saves
costs for project and organization which otherwise may require a special trainer for coaching.

Overview of Telecom Domain

Telecom industry is becoming a top performing industry in the last few years.

This industry has a unique set of challenges from the technology front and the customer demands due to its wide
range of sectors. Telecom industry consists of a set of sectors like wireless communication, satellite communication,
Internet Service Provider etc.

Telecom industry builds, maintains and operates telecommunication network and thereby makes communication
possible globally through internet or phone for a human being and this service plays a vital role in anyone’s life.

Business Processes in Telecom Industry

A good understanding of the business processes in a must for testing a telecom project. This will help to test an end
to end telecom application.

Telecom services are based on the below two systems:

#1) Operations Support Systems (OSS):
OSS supports back-office activities like telecom network, provisioning, maintaining customer service, Inventory etc.
Sometimes it also called as Operational Support Systems.

#2) Business Support Systems (BSS):

BSS deals with Customer Relationship Manager (CRM) and processes such as generating invoices, IVR’s Call
Centers, taking orders, processing bills, collecting payments, etc. Basically, customer-facing activities are involved in
Business Support Systems.

OSS and BSS are related to each other and that is explained clearly in the below diagram:
BSS and OSS are separated as shown in above diagram in which passing the customer data or request from the
BSS to OSS and provides the required set-up, later activation is done by the OSS and again details are passed on to
the customer-facing application from the BSS.

Understanding the following business processes in the Telecom industry is essential while testing any
telecom application:
#1) In the Telecom Industry, it’s the provider who wants to increase his customers and for that purpose, the Telecom
Service Provider (TSP) approaches to the customers to provide a new service and checks if the customer is really
interested in his service.
#2) If a customer feels that the service is good and wants to go with a specific service then the customer generates
an inquiry. Here, basically, the customer is more interested in the quotation of the service or plan.
#3) Once the customer is satisfied with the initial details and quotes provided by the service provider then the
customer orders a service to the TSP.
#4) Now its the service provider’s responsibility for technical evaluation as if the service can be provided in that area
or not, all requirements of a customer can be fulfilled or not etc. After the successful evolution, TSP actually starts
working on the execution of the service request to the customer.
#5) TSP always tracks the order status, due to any reason if the order implementation stops then the TSP takes
priority to resolve the issue and continues to give service to the customer. After all, in today’s world, customer
satisfaction holds the key to success.
#6) After successful implementation, client or customer starts using the services and of course, billing also starts from
the service provider’s end. The billing will be generated as per the quotation provided earlier to the customer.
#7) For any technical problems, service assurance team will always be available to support the customer service.
Telecom business process stated above is explained in detail using the below diagram:
(Note: Click on the below image for an enlarged view)

[image source]
Protocol Testing
In telecommunication, protocol means a set of rules which need to be followed when two connections communicate
with each other and these protocols exist at different levels.

In the Telecom industry, Protocols are classified into two categories as shown below:
#1) Routed Protocols:
In the Telecom industry, the user sends data from one network to another and this data contains files, e-mails etc.
Using this Routed protocols, the user can send such data to a different network at a different location.
#2) Routing Protocols:
Different types of data can be transferred using Routers. Routing protocols are used to decide the route of the routers
and are used between the routers only.

Types of Protocols
Given below are the various types of Protocols:
#1) Transmission Control Protocol/ Internet protocol (TCP/IP):
This protocol is used to send information through the internet using packets.

#2) File Transfer Protocol (FTP):

It is used to transfer a file from one network to another network.

#3) Simple Mail Transfer Protocol (SMTP):

During e-mail communication, this type of protocol is used to send & receive emails.

#4) Hypertext Transfer Protocol (HTTP):

It is used to transfer HTML pages in an encrypted form.

#5) Layer 2 Protocol:

It is a Data Link Layer protocol. E.g. Ethernet, Token Ring.
#6) Layer 3 Protocol:
It is a Network Layer Protocol. E.g. Internet Protocol.
Protocol Testing Process
 Protocol Analyzer and Simulator are required for protocol testing. Here, analyzers and simulators are
required for testing the Switching application.
 Protocol Analyzer checks the decoding of calls & Session Analysis and the Simulator simulates different
elements of the networking system.
 Protocol Testing is carried out by the Device Under Test (DUT) to other devices like switches, routers and
configuring protocol in it.
 In protocol testing, we check whether we get the packet X and when we expect it is called “Correctness”.
We also check the “Latency time” i.e. how much time a packet takes for transit. “Bandwidth” is checked by
using how many packets can be sent per second.
The use case diagram given below will help you to understand the Protocol Testing process:

Sample Test Case for Protocol Testing

Show   entries

Search:
 Step
Step description Expected Result
No

Step Start the communication process Communication should be established

1 successfully

Step On the command prompt, enter “Transmit successful” message should be

2 the command as ‘Ping-w’ displayed

Step To count the echo request, provide System should start pining and a message should
3 command as ‘Ping-n’ be displayed as “Transmit successfully”

Showing 1 to 3 of 3 entries

PreviousNext

There are different activities that are to be performed while providing service to the customers in the telecom industry.

The below details will show which department is responsible for which activities:

Show   entries

Search:

Telecom
Activities associated with the department
Department

Pre-sales It takes care of all the sales related activities like advertisements, different
kind of services, discounts applicable for each service, promos etc

Ordering This department deals with of any order such as an order for a new
connection or discontinuing of existing connection

Provisioning When Telecom Service Provider (TSP) approaches to the customer for any
new service and customer placed a request to start the service then
“Provisioning” department actually provides required connection to the
customer

Billing When an order has been completed successfully by ordering and provisioning
team and the customer starts using the actual service then billing also starts.
In this department, all activities related to the billing take place

Service While using service if the customer has any technical problem then this
 Telecom
Activities associated with the department
Department

Assurance department comes into the picture. There is always team available for issue
resolution for the customer. In case of any technical failure, this team resolves
the problem

Inventory Inventory system keeps all data like from customer inquiry, order placed
System successful implementation of the order, customer satisfaction history,
customer’s issues, resolution of issues etc. This system acts as a storehouse of
all information

Showing 1 to 6 of 6 entries

PreviousNext

Testing Types Performed on Telecom Software or Project

The types of testing that are given below are performed on a Telecom software.

#1) Conformance Testing:

Conformance testing is a formal way for testing standards. Telecom testing is spread across various network
elements, protocols, and devices developed by different organizations. These elements often refer each other and
nowadays it is important to ensure if the relevant data standards between two network systems are maintained.

In Conformance testing, the following testing is performed:

 Electrical interface compatibility
 Conformance of transport layer
 Conformance of protocols
#2) IVR Testing:
An IVR is “Interactive Voice Response” system which is the most important one in telecom testing. IVR consists of
different menus and each menu has different choices. This type of testing is usually carried out over the phone. The
user has to dial the specific customer care number and the call will get transferred to the customer care agent based
on the choice selected by the user.

This type of system requires a comprehensive testing so that the users are not confused about the options in the
system and they are able to complete their transaction hassle free. IVR system can be verified using voice and DTMF
(Dual-tone multi-frequency) response.

For Example, the steps mentioned below are involved to get the saving account balance of the customer:
 The user dials IVR line and hears welcome prompt and menu option.
 IVR prompts for verification.
 The user enters his or her credentials using DTMF system.
 IVR plays menu options and press 1 for account information, 2 for funds transfer.
 User inputs 1, for his account information.
 IVR plays press 1 for the latest balance or 2 for the last 3 transactions.
 The user enters 1 using DTMF.
 IVR prompts for the customers latest available balance.
Further reading => IVR Testing detailed process
#3) Interconnection Testing:
The name itself explains that testing of connection of two separate networks or their elements. The basic idea behind
this type of testing is to check if the connected elements communicate with each other properly and there is no
technical fault.

#4) Interoperability Testing:

Interoperability Testing means testing the devices developed by multiple manufacturers and if these devices are
interacting with other software and equipment properly or not.

For Example, in interoperability testing, mobile phones are tested against the requirement of different networks and
they should work properly. Also, different mobile networks must work properly with different mobile phones. This type
of testing can reveal the problems which conformance testing could not be able to identify.
#5) Performance Testing:
Performance testing is the verification of a device under test which meets an acceptable level under maximum load.
Performance testing allows the device to identify its capacity with maximum communication traffic.

#6) Security Testing:

Security testing is to penetrate the network and application using different tools and technology and check if the
system is free from vulnerability. This is also used to test if any security breaches happened and if so then how much
loss would occur for the organization or to the product.

Security testing is also used to test how good security practice is implemented for the product and how good the
system is configurable.

Automation of Telecom Process

Due to the growing demand from the buyers and growing capabilities in the technological field, testing is exponential
for service providers and telecommunication manufacturers. This is achieved by using automation framework for an
end to end testing which will increase the profitability.

Different testing types can be automated using automation framework like device testing, network testing, system
testing etc which in turn will increase the test coverage and reduce the time for execution.

The robot-based framework is used for telecom-based testing. Robot Framework is a test automation framework for
acceptance testing. Robot framework is an open source software and the libraries required with Robot framework for
telecom testing are also open sources.
 An automated telecom solution provides consistent testing which can be customized based on the project
requirements.
 Usually, Telecom Service Provider (TSP) takes around 6 to 8 months to complete all the activities manually.
These manual efforts introduce few error-prone results.
 Automation in Telecom industry reduces the errors drastically and completes the entire process flow within a
short period of time.
 Automation process guarantees the correct execution of telecom process flow which gains the confidence of
the customer.
Tools used during Telecom Testing Project
Given below are few tools that are used in telecom testing.

Show   entries

Search:

Tool Used in / Useful for

Wireshark / Ethereal It is an open source tool. It used in Protocol testing for network
 Tool Used in / Useful for

troubleshooting, analysis.

Nethawk It is used for SS7 protocol testing

Etherpeek Used for IP testing

Glomosim simulator It is used to simulate wireless and wired network systems

Abacus5000 Session Initiation Protocol (SIP) testing

Test Mobile System (TMS) It is a basic tool to perform wireless network drive testing,
analysis and monitoring

CDMA Air Interface Tester It is a network optimization tool used for minimize the call drop
(CAIT) and increase the coverage

Communication Network It is used for detecting terminals quickly and rescue of multiple
Tester (CNT) terminals

Showing 1 to 8 of 8 entries

PreviousNext

Note:  Mentioned above are only a few tools that are used in telecom testing. There are other varieties of tools as well
that are used in telecom testing but here the list is very limited and short.
Sample Test Case in Telecom testing
There are various testing types available in telecom testing as mentioned in the above section. However, in this
article, we will be covering the sample test case of one of the functionality Billing System which includes various
steps for testing.
There are few pre-requisites that must be completed before the start of the test like connection should already
establish and the customer must have offered different services etc.

Show   entries

Search:

Step
Step description Expected Result
No

Step Validate that customer’s telephone number Customer’s telephone number should
1 is registered under telecom operator be registered with telecom operator
 Step
Step description Expected Result
No

Step Validate that the number is working and Telephone number should be of 10
2 given number is of expected number of digits digits and should be working
(usually for mobile number, the digits are of
10 digits)

Step Validate that the generated bill contains all The generated bill should contain
3 accurate details of calls with date and time accurate details of call with respective
date and time

Step Validate that customer has paid all existing Existing un-paid bills should be
4 bills, if not then show it on the front screen displayed on front screen
as per business requirement

Step Validate that if customer already paid some Current bill displayed to the customer
5 excess bill then the excess amount should should deduct excess amount paid in
deduct from current bill and then display last bill and the remaining bill should
remaining bill to the customer be displayed to the customer

Step Validate that bill is generated only for those Bill should be generated for services
6 services which are active on the customer’s which are activated by customer
number

Step Validate that if any of the service is stopped Bill should be generated based on the
7 in-between the billing cycle then bill should pro-rata basis
be generated for that service up to active
date and not for entire billing cycle

Step Validate that if any of the free service Services which are free to the
8 activated on the number then it should be customer should be excluded from the
excluded from the billing usages billing

Showing 1 to 8 of 8 entries

Conclusion
The telecom industry includes various fields like network, protocols, wired communication, wireless communication,
broadband connection etc.

Hence in order to test such wide range of fields, one must have knowledge of the domain and different kind of tools
that are being used to carry out effective and in-depth testing.
This article will give all the basic information about telecom domain to those who are a newbie to the telecom domain.

Web Application Testing: 8 Step Guide to

Website Testing
Before we pen down more details on the type of web testing, lets quickly define Web Testing.

What is Web Testing?

WEB TESTING, or website testing is checking your web application or website for potential
bugs before its made live and is accessible to general public. Web Testing checks for
functionality, usability, security, compatibility, performance of the web application or website.

During this stage issues such as that of web application security, the functioning of the site, its
access to handicapped as well as regular users and its ability to handle traffic is checked.

How to test Web Application

In Software Engineering, the following testing types/technique may be performed depending on
your web testing requirements.

1. Functionality Testing:
This is used to check if your product is as per the specifications you intended for it as well as the
functional requirements you charted out for it in your developmental documentation. Web based
Testing Activities includes:

Test all links in your webpages are working correctly and make sure there are no broken links.
Links to be checked will include -

 Outgoing links
 Internal links
 Anchor Links
 MailTo Links

Test Forms are working as expected. This will include-

 Scripting checks on the form are working as expected. For example- if a user does not
fill a mandatory field in a form an error message is shown.
 Check default values are being populated
 Once submitted, the data in the forms is submitted to a live database or is linked to a
working email address
 Forms are optimally formatted for better readability
Test Cookies are working as expected. Cookies are small files used by websites to primarily
remember active user sessions so you do not need to log in every time you visit a website.
Cookie Testing will include

 Testing cookies (sessions) are deleted either when cache is cleared or when they reach
their expiry.
 Delete cookies (sessions) and test that login credentials are asked for when you next
visit the site.

Test HTML and CSS to ensure that search engines can crawl your site easily. This will include

 Checking for Syntax Errors

 Readable Color Schemas
 Standard Compliance. Ensure standards such W3C, OASIS, IETF, ISO, ECMA, or WS-I
are followed.

Test business workflow- This will include

 Testing your end - to - end workflow/ business scenarios which takes the user through a
series of webpages to complete.
 Test negative scenarios as well, such that when a user executes an unexpected step,
appropriate error message or help is shown in your web application.

Tools that can be used: QTP , IBM Rational , Selenium

2. Usability testing:
Usability Testing has now become a vital part of any web based project. It can be carried out
by testers like you or a small focus group similar to the target audience of the web
application.

Test the site Navigation:

 Menus, buttons or Links to different pages on your site should be easily visible and
consistent on all webpages

Test the Content:

 Content should be legible with no spelling or grammatical errors.

 Images if present should contain an "alt" text

Tools that can be used: Chalkmark, Clicktale, Clixpy and Feedback Army

3.Interface Testing:
Three areas to be tested here are - Application, Web and Database Server

 Application: Test requests are sent correctly to the Database and output at the client
side is displayed correctly. Errors if any must be caught by the application and must be
only shown to the administrator and not the end user.
 Web Server: Test Web server is handling all application requests without any service
denial.
 Database Server: Make sure queries sent to the database give expected results.

Test system response when connection between the three layers (Application, Web and

Database) cannot be established and appropriate message is shown to the end user.

Tools that can be used: AlertFox, Ranorex

4. Database Testing:
Database is one critical component of your web application and stress must be laid to test it
thoroughly. Testing activities will include-

 Test if any errors are shown while executing queries

 Data Integrity is maintained while creating, updating or deleting data in database.
 Check response time of queries and fine tune them if necessary.
 Test data retrieved from your database is shown accurately in your web application

Tools that can be used: QTP, Selenium

5. Compatibility testing.
Compatibility tests ensures that your web application displays correctly across different devices.
This would include-

Browser Compatibility Test: Same website in different browsers will display differently. You
need to test if your web application is being displayed correctly across browsers, JavaScript,
AJAX and authentication is working fine. You may also check for Mobile Browser Compatibility.

The rendering of web elements like buttons, text fields etc. changes with change in Operating
System. Make sure your website works fine for various combination of Operating systems such
as Windows, Linux, Mac and Browsers such as Firefox, Internet Explorer, Safari etc.

Tools that can be used: NetMechanic

6. Performance Testing:
This will ensure your site works under all loads. Software Testing activities will include but not
limited to -
  Website application response times at different connection speeds
 Load test your web application to determine its behavior under normal and peak loads
 Stress test your web site to determine its break point when pushed to beyond normal
loads at peak time.
 Test if a crash occurs due to peak load, how does the site recover from such an event
 Make sure optimization techniques like gzip compression, browser and server side
cache enabled to reduce load times

Tools that can be used: Loadrunner, JMeter

7. Security testing:
Security Testing is vital for e-commerce website that store sensitive customer information like
credit cards. Testing Activities will include-

 Test unauthorized access to secure pages should not be permitted

 Restricted files should not be downloadable without appropriate access
 Check sessions are automatically killed after prolonged user inactivity
 On use of SSL certificates, website should re-direct to encrypted SSL pages.

Tools that can be used: Babel Enterprise, BFBTester and CROSS

8. Crowd Testing:
You will select a large number of people (crowd) to execute tests which otherwise would have
been executed a select group of people in the company. Crowdsourced testing is an interesting
and upcoming concept and helps unravel many a unnoticed defects.

Tools that can be used: People like you and me !!!. And yes , loads of them!

This concludes the tutorial. It includes almost all testing types applicable to your web
application.

As a Web-tester its important to note that web testing is quite an arduous process and you are
bound to come across many obstacles. One of the major problems you will face is of
course deadline pressure. Everything is always needed yesterday! The number of times
the code will need changing is also taxing. Make sure you plan your work and know clearly
what is expected of you. Its best define all the tasks involved in your web testing and
then create a work chart for accurate estimates and planning.

Web Application Testing Checklist:

Example Test Cases for Website
While testing the web applications, one should consider the below mentioned template. The
below mentioned checklist is almost applicable for all types of web applications depending on
the business requirements.

The web application testing checklist consists of-

 Usability Testing
 Functional Testing
 Compatibility Testing
 Database Testing
 Security Testing
 Performance Testing

Now let's look each checklist in detail:

Usability Testing
What is Usability Testing?

 Usability testing is nothing but the User-friendliness check.

 In Usability testing, the application flow is tested so that a new user can understand the
application easily.
 Basically, system navigation is checked in Usability testing.

What is the purpose or Goal of Usability testing?

A Usability test establishes the ease of use and effectiveness of a product using a standard
Usability test practices.

Example Usability Test Cases

 Web page content should be correct without any spelling or grammatical errors
 All fonts should be same as per the requirements.
 All the text should be properly aligned.
 All the error messages should be correct without any spelling or grammatical errors and
the error message should match with the field label.
 Tool tip text should be there for every field.
 All the fields should be properly aligned.
 Enough space should be provided between field labels, columns, rows, and error
messages.
 All the buttons should be in a standard format and size.
 Home link should be there on every single page.
 Disabled fields should be grayed out.
 Check for broken links and images.
 Confirmation message should be displayed for any kind of update and delete operation.
 Check the site on different resolutions (640 x 480, 600x800 etc.?)
 Check the end user can run the system without frustration.
 Check the tab should work properly.
 Scroll bar should appear only if required.
  If there is an error message on submit, the information filled by the user should be there.
 Title should display on each web page
 All fields (Textbox, dropdown, radio button, etc) and buttons should be accessible by
keyboard shortcuts and the user should be able to perform all operations by using
keyboard.
 Check if the dropdown data is not truncated due to the field size. Also, check whether
the data is hardcoded or managed via administrator.

Functional Testing:
What is Functional Testing?

 Testing the features and operational behavior of a product to ensure they correspond to
its specifications.
 Testing that ignores the internal mechanism of a system or component and focuses
solely on the outputs generated in response to selected inputs and execution conditions.

What is the purpose or Goal of Functional testing?

 The goal of Functional Testing is to verify whether your product meets the intended
functional specifications mentioned in your development documentation.

Example Functional Test Scenarios:

 Test all the mandatory fields should be validated.

 Test the asterisk sign should display for all the mandatory fields.
 Test the system should not display the error message for optional fields.
 Test that leap years are validated correctly & do not cause errors/miscalculations.
 Test the numeric fields should not accept the alphabets and proper error message
should display.
 Test for negative numbers if allowed for numeric fields.
 Test division by zero should be handled properly for calculations.
 Test the max length of every field to ensure the data is not truncated.
 Test the pop up message ("This field is limited to 500 characters") should display if the
data reaches the maximum size of the field.
 Test that a confirmation message should display for update and delete operations.
 Test the amount values should display in currency format.
 Test all input fields for special characters.
 Test the timeout functionality.
 Test the Sorting functionality.
 Test the functionality of the buttons available
 Test the Privacy Policy & FAQ is clearly defined and should be available for users.
 Test if any functionality fails the user gets redirected to the custom error page.
 Test all the uploaded documents are opened properly.
 Test the user should be able to download the uploaded files.
 Test the email functionality of the system.
 Test the Java script is properly working in different browsers (IE, Firefox, Chrome, safari
and Opera).
 Test to see what happens if a user deletes cookies while in the site.
  Test to see what happens if a user deletes cookies after visiting a site.
 Test all the data inside combo/list box is arranged in chronological order.

Compatibility Testing:
What is Compatibility testing?

 Compatibility testing is used to determine if your software is compatible with other

elements of a system with which it should operate, e.g. Browsers, Operating Systems, or
hardware.

What is the purpose or Goal of Compatibility testing?

 The purpose of Compatibility testing is to evaluate how well software performs in a

particular browser, Operating Systems, hardware or software.

Sample Compatibility Test Scenarios:

 Test the website in different browsers (IE, Firefox, Chrome, Safari and Opera) and
ensure the website is displaying properly.
 Test the HTML version being used is compatible with appropriate browser versions.
 Test the images display correctly in different browsers.
 Test the fonts are usable in different browsers.
 Test the java script code is usable in different browsers.
 Test the Animated GIF's across different browsers.

Database Testing:
What is Database Testing?

 In Database testing backend records are tested which have been inserted through the
web or desktop applications. The data which is displaying in the web application should
match with the data stored in the Database.

To perform the Database testing, the tester should be aware of the below mentioned
points:

 The tester should understand the functional requirements, business logic, application
flow and database design thoroughly.
 The tester should figure out the tables, triggers, store procedures, views and cursors
used for the application.
 The tester should understand the logic of the triggers, store procedures, views and
cursors created.
 The tester should figure out the tables which get affected when insert update and delete
(DML) operations are performed through the web or desktop applications.

With the help of the above mentioned points, the tester can easily write the test
scenarios for Database testing.
Example Test Cases for Database Testing:

 Verify the database name: The database name should match with the specifications.
 Verify the Tables, columns, column types and defaults: All things should match with the
specifications.
 Verify whether the column allows a null or not.
 Verify the Primary and foreign key of each table.
 Verify the Stored Procedure:
 Test whether the Stored procedure is installed or not.
 Verify the Stored procedure name
 Verify the parameter names, types and number of parameters.
 Test the parameters if they are required or not.
 Test the stored procedure by deleting some parameters
 Test when the output is zero, the zero records should be affected.
 Test the stored procedure by writing simple SQL queries.
 Test whether the stored procedure returns the values
 Test the stored procedure with sample input data.
 Verify the behavior of each flag in the table.
 Verify the data gets properly saved into the database after each page submission.
 Verify the data if the DML (Update, delete and insert) operations are performed.
 Check the length of every field: The field length in the back end and front end must be
same.
 Verify the database names of QA, UAT and production. The names should be unique.
 Verify the encrypted data in the database.
 Verify the database size. Also test the response time of each query executed.
 Verify the data displayed on the front end and make sure it is same in the back end.
 Verify the data validity by inserting the invalid data in the database.
 Verify the Triggers.

What is Security Testing?

Security Testing involves the test to identify any flaws and gaps from a security point of view.

Sample Test Scenarios for Security Testing:

 Verify the web page which contains important data like password, credit card numbers,
secret answers for security question etc should be submitted via HTTPS (SSL).
 Verify the important information like password, credit card numbers etc should display in
encrypted format.
 Verify password rules are implemented on all authentication pages like Registration,
forgot password, change password.
 Verify if the password is changed the user should not be able to login with the old
password.
 Verify the error messages should not display any important information.
 Verify if the user is logged out from the system or user session was expired, the user
should not be able to navigate the site.
 Verify to access the secured and non-secured web pages directly without login.
 Verify the “View Source code” option is disabled and should not be visible to the user.
 Verify the user account gets locked out if the user is entering the wrong password
several times.
  Verify the cookies should not store passwords.
 Verify if, any functionality is not working, the system should not display any application,
server, or database information. Instead, it should display the custom error page.
 Verify the SQL injection attacks.
 Verify the user roles and their rights. For Example, the requestor should not be able to
access the admin page.
 Verify the important operations are written in log files, and that information should be
traceable.
 Verify the session values are in an encrypted format in the address bar.
 Verify the cookie information is stored in encrypted format.
 Verify the application for Brute Force Attacks

What is Performance Testing?

Performance Testing is conducted to evaluate the compliance of a system or component with
specified performance requirements.

General Test scenarios:

 To determine the performance, stability and scalability of an application under different

load conditions.
 To determine if the current architecture can support the application at peak user levels.
 To determine which configuration sizing provides the best performance level.
 To identify application and infrastructure bottlenecks.
 To determine if the new version of the software adversely had an impact on response
time.
 To evaluate product and/or hardware to determine if it can handle projected load
volumes.

How to do Performance testing? By Manual Testing or by Automation

Practically it is not possible to do the Performance Testing manually because of some
drawbacks like:

 More number of resources will be required.

 Simultaneous actions are not possible.
 Proper system monitoring is not available.
 Not easy to perform the repetitive task.

Hence to overcome the above problems we should use Performance Testing tool. Below is the
list of some popular testing tools.

 Apache JMeter
 Load Runner
 Borland Silk Performer.
 Rational Performance Tester
 WAPT
 NEO LOAD