(Approved by AICTE, New Delhi & Affiliated to Anna University, Chennai)

NH- 47, Palakkad Main Road, Navakkarai Po, Coimbatore – 641 105.

DEPARTMENT OF

ARTIFICIAL INTELLIGENCE
AND DATA SCIENCE

RECORD NOTEBOOK

Name: ___________________________________________

Register No: ______________________________________

Subject Code/Title: ________________________________

Year/Semester: ___________________________________

Academic Year:___________________________________
 (Approved by AICTE, New Delhi & Affiliated to Anna University, Chennai)

NH- 47, Palakkad Main Road, Navakkarai Po, Coimbatore – 641 105.

DEPARTMENT OF

ARTIFICIAL INTELLIGENCE AND DATA SCIENCE

CERTIFICATE
This is to certify that Mr./Ms._____________________________________
Reg. No._____________________________________________ of____ Semester
____Year B.Tech. (Artificial Intelligence and Data Science) has completed his/her
practical work in the_____________________________________________
laboratory during the academic year 2024-25.

Faculty In-charge Head of the Department

Submitted for the University practical examination held on :_______________

INTERNAL EXAMINER EXTERNAL EXAMINER

 INDEX
Page Staff
S. No. Name of the Experiment Marks
No. Sign.

Average:
Exp. No.: Date:

TEST PLAN FOR TESTING AN E-COMMERCE WEB/MOBILE APPLICATION

Lab Objectives:

 Understand the process of testing an e-commerce web/mobile application.

 Familiarize yourself with test plan.
INTRODUCTION

The purpose of this test plan is to outline the testing approach for an e-commerce web/mobile
application, specifically www.amazon.in. The goal is to ensure that the application functions
as intended, meets user requirements, and provides a seamless shopping experience.

Scope

The scope of this test plan includes testing the core functionalities of the e-commerce
application, such as browsing products, adding items to the cart, placing orders, and
managing user accounts. It also covers testing across different platforms, including web and
mobile.

Test Objectives

 Validate the functionality of the e-commerce application.

 Verify that the application is user-friendly and provides a smooth shopping
experience.
 Ensure that the application is secure and protects user data.
 Test the application's compatibility across different browsers and devices.
 Evaluate the performance and scalability of the application under various load
conditions.
 Identify and report any defects or issues found during testing.
Test Environment

 Web browsers: Chrome, Firefox, Safari, and Edge.

Mobile devices: iOS and Android.

Test management tool: Jira or any other preferred tool.

Test automation tool: Selenium WebDriver or any other preferred tool.

Load testing tool: JMeter or any other preferred tool.

Test Approach

1. Requirements Analysis:
 Review the functional and non-functional requirements of the e-commerce
application.
 Identify testable features and prioritize them based on criticality.
2. Test Design:
 Create test scenarios and test cases for each identified feature.
 Include positive and negative test cases to cover different scenarios.
 Define test data and test environment setup requirements.
3. Test Execution:
 Execute test cases manually or using test automation tools.
 Log defects in the test management tool and track their status.
 Perform regression testing after each bug fix or application update.
4. Performance Testing:
 Design and execute performance tests to evaluate the application's response time,
throughput, and scalability.
 Simulate different user loads and monitor system resources during testing.
 Identify performance bottlenecks and suggest improvements if needed.
5. Security Testing:
 Conduct security testing to identify vulnerabilities and ensure the application protects
user data.
 Test for common security issues like SQL injection, cross-site scripting (XSS), and
authentication vulnerabilities.
 Implement security best practices and follow industry standards.
6. Compatibility Testing:
 Test the application on different browsers, versions, and mobile devices.
 Verify that the application renders correctly and functions as expected across various
platforms.
Test Deliverables

 Test plan document.

  Test scenarios and test cases.
 Test execution reports.
 Defect reports with severity and priority.
 Performance test reports.
 Security test reports.
Conclusion

By following this test plan, you can ensure comprehensive testing of the e-commerce
web/mobile application (www.amazon.in). It covers functional, performance, security, and
compatibility testing, enabling you to deliver a high-quality and reliable application to end-
users.
Exp. No.: Date:

TEST CASES FOR TESTING E-COMMERCE APPLICATION

OBJECTIVE:

 Gain hands-on experience with testing e commerce application

 Learn how to develop test cases
Now that we have the different types of testing applicable, it’s time to delve into the sample
test cases for ecommerce website. To create practical test cases for ecommerce website, one
must understand the structure of a typical site.

There are many features in an e-Commerce website – hero carousel/slider, search, filter,
product details, payments, checkout, etc. each having a pre-defined functionality. For
example, every search bar should show relevant results, i.e., searching for electronics should
show all categories like mobiles, TVs, cameras, etc.

Going ahead, we’ll pick a few significant features and list the test cases for eCommerce
website:

General Ecommerce Test Cases

 The user should be able to navigate to all the pages in the website
 There should be a fallback page for any page load errors.
 Verify that all the links and banners work properly
 Search results should be displayed with the most relevant item being shown first
 All data related to the product – title, price, images, and description are all visible
clearly
 Maintain a session for each user and test verify the session times out after a while
Login/Registration test cases for Online Shopping Website
  Test for valid username and password
 Test “Forgot Password” and Reset Password functionality
 Validate If user is registered or not, and if not, provide an option to create an account
 Show Login screen by default for registered user
 Test that all fields are mandatory
Seller Product Creation Test Cases

 For sellers who want to create their catalog, they should be able to add their products,
and this flow should be tested.
 Test that authenticated sellers can access authorized product creation panels under
authorized categories.
 Test the maximum product creation limit to avoid adding more products to the
catalog.
 Test that seller’s products are visible after some time
 Test the product creation process is working fine for the seller
 Test that there are no duplicate products
Search Bar Test Cases for Online Shopping Website

 Test what parameters the search is based on – for example, product name, brand
name, category, etc.
 Test if the search results are relevant
 Number of results to be displayed per page
 Test whether the search API is being called at every keystroke. (This isn’t
recommended, as it would unnecessarily cause multiple API calls to the database)
Filter Results
Example of a filter

 Test if the user can filter based on all the parameters on the page
 The user should be able to see results with default search criteria when at least one of
the filter parameters isn’t mandatory
 Validation messages for invalid filter criteria
 When at least one filter criteria are required, and the user selects none, proper error
messages are shown

Product Detail Test Cases

 Test that all the product details are displayed correctly and that no empty/invalid
details are displayed.
  Product Images should be optimized for size and dimensions, which f urther helps
in performance testing.
 If there’s breadcrumb navigation, each link in the breadcrumb should be functional.
Below is an example of breadcrumb navigation.
 All the links(size, Pincode check, etc) about the product should be functional.
Shopping Cart

 Test that all items are added into the cart

 Test that all added items have at least a quantity, price, and delete option associated
with it
 Test that the user can increase/decrease the quantity from the cart
 If a user adds the same item to the cart the amount of that item should increase in the
cart
 On closing the tab/leaving the site, the items should still be in the cart upon returning
to the website.
 Checkout Page
 User should be able to add coupons
 User should be shown the total amount with the necessary breakup as applicable.
 User should be able to select the desired payment method
 On adding more items or increasing/decreasing quantity, the total should change
accordingly
 Calculate shipping costs based on shipping methods
 Right address should be selected and the user should be able to edit/add the address
 Payments
  Perform security testing if in case the user’s credit card details need to be saved
 For returning customers, they should be redirected to log in for checkout
 User should be logged out after the session times out
 Emails/test confirmation when the order is confirmed
As you can see, an eCommerce website has many more tests or features, and testing each is
very time-consuming and requires effort. Thankfully, a few tools and techniques are available
to ease the website testing process.
Exp. No.: Date:

TEST THE E-COMMERCE APPLICATION AND REPORT THE DEFECTS IN IT

OBJECTIVE:

To test the e-commerce application and report the defects in it.

E-COMMERCE TESTING CHECKLIST

We have listed important segments and test cases for eCommerce website testing below.

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:

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 does it load 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 the 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 sorts of options have to be available- based on Brand, Price, and Reviews/ratings

etc.

How many results are displayed per page?

For the multi-page results, are there options to navigate to them

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 image of the product

Price of the product

Product specifications

Reviews

Check out options

Delivery options

Shipping information

In-stock/Out of stock

Multiple color and variation options

Breadcrumb navigation for the categories (highlighted in red below). If navigation such as

this 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 your 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

 The user can add more items to the cart and the total should reflect the same

 Update the content added to the cart which should also reflect in the total

 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 for different payment options

 If allowing you to check out as a Guest, simply finish the purchase and provide an

option to register at the end

 Returning customers – Login to check out

 User sign up

 If you are storing a customer’s 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.

 Email/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.

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.

Types of E-commerce Testing Techniques

Since e-commerce applications operate on an international scale, they need to fulfill certain

requirements before they can be launched. For this reason, web apps have to go through

diverse forms of testing to ensure that every facet of the system works flawlessly.

Here is a list of e-commerce testing techniques and approaches:

1. Functional Testing to Avoid Post-Launch Issues

Regardless of how well you develop your e-commerce app, errors in your wireframe will

always remain that may disrupt your app functionality. Thus, the quality of any application is

crucial for customer satisfaction and retention. Functional testing sets the foundation for a

well-functioning app, validating that all features work according to requirements.

Important traits that need to be tested include

 Login/ Sign-in system

 Search and filters page

 Order details page

 Coupon codes and Deals

 Order tracking

 Shopping cart page

 Checkout page

2. Usability Testing for Smooth Buying Experience

An e-commerce app’s or website’s usability is critical in facilitating users during the

purchase. Comprehensive usability testing creates a superior app experience. A

shocking 88% of people will not return to a website they had a bad experience with. So,

refusing to invest in a mobile-first design implementation can cost far more than one could

expect.

However, Testing every possible device on the market is impossible. Testing on the right

devices would be the next best thing.

3. Security Testing for Seamless Transactions

The risk of theft, fraud, and security breaches is a real threat to e-commerce apps. No one

likes to get stuck on the payments page. So, it is crucial to ensure a safe, smooth, and secure

payment process by testing thoroughly.

Security Testing addresses the following parameters:

 Ensure all supported and secured payment options.

 Verify that all the data exchanges and transmissions between the user’s device and the

app server occur through HTTPS protocol.

 Encryption of the user’s data like credit/debit card details, bank account credentials,

and other confidential data should occur over a secured channel.

 Validate whether there is any information loss during the transmission and ensure that

the recovery systems work perfectly in case of any loss.

 Check whether the encryption of the sensitive information is successful and no

storage of passwords in the cookies.

With BrowserStack App Live, you can be assured of uncompromising e-commerce app

testing security. Pristine devices and browsers are available for everyone, every time. Simply

need to sign up, choose the browser-device-OS combination, and start testing to ensure

operability.

4. Performance Testing For Optimum Functionality

Slow performance can kill performance even on a web app that gets a great score. That is

why performance testing is crucial in SDLC. It guarantees that the e-commerce apps function

smoothly across all browsers.

Types of performance testing include:

 Stress testing
  Load testing

 Volume testing

 Spike testing

 Scalability testing

5. Cross-Browser Testing for Consistent App Experiences

Last but not least, every e-commerce website needs to be accessed from multiple browsers-

OS-device combinations. The only way to ensure this is to perform end-to-end cross-browser

testing across real browsers and devices.

So, as you can see, conducting thorough e-commerce automation testing is vital to reduce

bugs and improve performance. Some of the key benefits of E-Commerce mobile app testing

are:

 Enhanced Application Performance

 Compatibility across Browsers

 Secured Application from Vulnerabilities

 Ensures Superior App UX.

With BrowserStack by your side in your product release cycle, your team can test mobile

apps on real mobile devices and verify their performance in real-world circumstances.

Instead of setting up and maintaining a massive on-premise device lab, teams and individual

testers can simply log in to access 3000+ real Android and iOS devices on the cloud for e

Commerce testing.
Exp. No.: Date:

DEVELOP THE TEST PLAN AND DESIGN THE TEST CASES FOR AN
INVENTORY CONTROL SYSTEM

OBJECTIVE:

To develop the test plan and design the test cases for an inventory control system

Creating a practical test plan and test cases for an inventory control system involves
considering real-world scenarios and ensuring that the system meets the practical needs of
users.

Test Plan

1. Introduction

Brief overview of the inventory control system and its practical significance.

Emphasis on the system's role in streamlining day-to-day inventory operations.

2. Test Objectives

Ensure the system effectively manages real-world inventory scenarios.

Validate the system's usability and efficiency in practical settings.

3. Scope

Testing of key features used in daily operations (e.g., product addition, order processing,
reporting).

Practical aspects of user interactions and system responses.

4. Test Environment

Testing will be conducted in an environment that mirrors the actual production environment.

Realistic data sets reflecting the variety and volume of products.

5. Test Deliverables

Detailed test cases for practical scenarios.

Practical insights into system performance and usability.

6. Testing Schedule

Testing will be conducted during regular business hours to simulate typical usage patterns.

Incremental testing to address immediate practical needs.

7. Test Team

Inclusion of end-users in the testing team to ensure practical perspectives.

Collaboration with the operations team for real-world insights.

8. Risks and Assumptions

Risks associated with disruptions to daily operations during testing.

Assumptions regarding the stability of the production environment.

9. Test Approaches

Emphasis on manual testing to replicate user interactions realistically.

Real-world scenario-based testing.

10. Test Cases

Test cases aligned with common inventory management tasks.

Emphasis on scenarios encountered in daily operations.

Test Cases

1. Receiving and Adding New Products

Practical scenario: Test the system's ability to efficiently add new products to the inventory
upon receipt.

2. Order Processing and Fulfilment

Practical scenario: Test the system's responsiveness in processing and fulfilling customer
orders in a timely manner.

3. Stock Replenishment

Practical scenario: Test the system's capability to trigger stock replenishment based on
predefined thresholds.

4. Batch Management

Practical scenario: Verify the system's ability to manage and track batches effectively,
especially for perishable goods.

5. Reporting for Decision Making

Practical scenario: Evaluate the system's reporting features for quick and informed decision-
making by management.

6. User Accessibility
Practical scenario: Test the user interface for simplicity and accessibility for users with
varying technical expertise.

7. Mobile Access

Practical scenario: Verify the usability of the system via mobile devices for users who need
on-the-go access.

8. System Resilience

Practical scenario: Test the system's ability to recover gracefully from unexpected
interruptions, ensuring minimal disruption to daily operations.

9. Integration with Point of Sale (POS)

Practical scenario: Validate seamless integration with POS systems to ensure accurate real-
time stock updates.

10. Vendor Interaction

Practical scenario: Test the system's ability to communicate with vendors for streamlined
procurement and order processing.
Exp. No.: Date:

EXECUTE THE TEST CASES AGAINST A CLIENT SERVER OR

DESKTOP APPLICATION AND IDENTIFY THE DEFECTS

OBJECTIVE:

To execute the test cases against a client server or desktop application and identify
the defects.

In real-time, each tester performs testing on Desktop applications, Client-Server applications,

or Web applications, or may work on multiple applications in parallel with different projects.
So testing is performed on different types of applications as mentioned above and the way we
perform testing in different environments also varies. Projects are broadly divided into two
types of:

 2 Tier Applications
 3 Tier Applications
In Client-Server application testing, the client sends requests to the server for specific
information and the server sends the response back to the client with the requested
information. Hence, this testing is also known as two-tier application testing. Few client-
server applications are Email, Web Server, FTP, etc

The picture below depicts what the Client-Server application looks like:
This type of testing is usually done for 2 tier applications (usually developed for LAN). We
will be having Front-end and Backend here.

Characteristics

 In the Client-Server applications, ‘.exe’ file is available on each client machine

whereas the application is loaded on the server machine.
 Internet connectivity is required to work on the Client-Server.
 The GUI feature is available on both client and server-side machines.
Types of Testing to Perform

Below are the different testing techniques to be performed:

 GUI Testing (UI Testing)

 Functional Testing
 Manual Testing
 Configuration Testing
 Load Testing (Back-end Testing)
 Performance Testing
 Interoperability Testing
 Compatibility Testing (Software/Hardware)
Merits & Demerits

Merits:

 All the data is located at the central location (Server), hence data is protected easily by
providing access to authorized users.
 Data can be accessed efficiently even if the server is located away from the clients.
Demerits:

 If multiple clients send requests to the same server in parallel, it leads to congestion in
the network because the server may get overloaded.
 Due to any reason, if a server fails then none of the client requests can be fulfilled and
this leads to the disruption of the client-server network.
 The cost of setting up and maintaining the server is high.
Web Application is a Three-Tier Application:
This has a browser (monitors data) [monitoring is done using HTML, Dhtml, XML,
JavaScript] -> webserver (manipulates data) [manipulations are done using programming
languages or scripts like adv java, asp, JSP, VBScript, JavaScript, Perl, ColdFusion, php] ->
database server (stores data) [data storage and retrieval is done using databases like Oracle,
SQL Server, Sybase, MySQL].

Client/Server Application:

Applications run in two or more machines.

Applications are menu-driven.

Connected mode (connection always exists until logout).

A limited number of users.

Less number of network issues when compared to the web app.

Web Application:

 Applications run in two or more machines.

 URL-driven
 Disconnected mode (stateless)
 Unlimited number of users.
Many issues like Hardware Compatibility, Browser Compatibility, Version Compatibility,
Security Issues, Performance Issues, etc.

As per the difference in both, the applications come from where and how to access the
resources. In Client-Server, once the connection is made, it will be in the state on connected,
whereas in case the web testing HTTP protocol is stateless, then there comes logic of cookies,
which is not in Client-Server. For Client-Server application, users are well known, whereas
for web application any user can log in and access the content, he/she will use it as per his
intentions.

So, there are always issues of security and compatibility for a Web Application.
Exp. No.: Date:

TEST THE PERFORMANCE OF THE E-COMMERCE APPLICATION

Significance of E-commerce Testing

E-commerce testing helps assess, verify, validate, and test e-commerce websites and apps.

It mainly checks for functionality, usability, security, compatibility, and performance of the

app or website. Besides that, e-commerce mobile app testing also helps evaluate whether the

app conforms to all standards, procedures, and regulations required for secure transactions.

The core objective of e-commerce testing is to ensure:

 All the pages of the e-commerce website are tested systematically, and transactions

are entirely validated and secure.

 There is no compromise on any crucial factors such as customer data security, mobile

responsiveness, loading time, user experience, etc.

 Testing, validating and verifying that the site or application is secured enough from

intruders and cyber hackers.

 That the particular e-commerce application is glitches-free, secure, and user-friendly

 Whether the application complies with the international standards, regulations, and

procedures to reduce cyber security threats.

 Overall, the e-commerce application testing process helps businesses identify

loopholes and get them fixed in a short cycle for faster product releases.

E-commerce Mobile App Testing Checklist

In the severe business of e-commerce mobile app development and testing, creating

ecommerce test cases and having a checklist is of prime concern. Let’s look at this quick

mobile app testing checklist that needs to be considered.

1. Home Page: The home page is the first-page interface where a buyer lands. Hence home

page should be good enough to bear the traffic load. The user-friendly home page/screen

empowers the entire mobile app and hence the QA team should scrutinize and test the

features of the home page accurately.

2. Search & Navigation: Total revenue in the Mobile App market is estimated to

hit US$420.70bn in 2022. Site search & navigation are two key revenue-driving factors

extensively used by your visitors to explore any mobile app and make buying decisions.

Hence, ensuring they are free of bugs gives a frictionless user experience from one app screen

to another.

3. Product Category and Filters: While testing an E-commerce app/ website, the QA team

should test all categories as wrong product mapping can make users bounce. Hence validating

the products against the detailed category is mandatory.

4. Product Details: Testing the product detail page is critical during performance testing of

the E-commerce application. Also, without a good product description page, an e-commerce

app is incomplete as buyers will shy away from incomplete information.

5.Checkout and Payment Process: When any system involves the payment process, it

becomes serious. As we know, frauds and scams are prevalent in the online market, so, we

need to be extra protective measures.

Exp. No.: Date:

AUTOMATE THE TESTING OF E-COMMERCE APPLICATIONS USING

SELENIUM

Selenium is a robust set of tools that supports rapid development of test automation
for web-based applications. Selenium provides a rich set of testing functions specifically
geared to the needs of testing of a web application. These operations are highly flexible,
allowing many options for locating UI elements and comparing expected test results against
actual application behavior. One of Selenium‘s key features is the support for executing one‘s
tests on multiple browser platforms.

Selenium Components

Selenium is composed of three major tools. Each one has a specific role in aiding the
development of web application test automation. Selenium-RC provides an API (Application
Programming Interface) and library for each of its supported languages: HTML, Java, C#,
Perl, PHP, Python, and Ruby. This ability to use Selenium-RC with a high-level
programming language to develop test cases also allows the automated testing to be
integrated with a project‘s automated build environment.

Selenium-Grid

Selenium-Grid allows the Selenium-RC solution to scale for large test suites or test
suites that must be run in multiple environments. With Selenium-Grid, multiple instances of
Selenium-RC are running on various operating system and browser configurations; Each of
these when launching register with a hub. When tests are sent to the hub they are then
redirected to an available Selenium-RC, which will launch the browser and run the test. This
allows for running tests in parallel, with the entire test suite theoretically taking only as long
to run as the longest individual test. * Tests developed on Firefox via Selenium-IDE can be
executed on any other supported browser via a simple Selenium-RC command line. **
Selenium-RC server can start any executable, but depending on browser security settings
there may be technical limitations that would limit certain features.

Flexibility and Extensibility

 Selenium is highly flexible. There are multiple ways in which one can add
functionality to Selenium‘s framework to customize test automation for one‘s specific testing
needs. This is, perhaps, Selenium‘s strongest characteristic when compared with proprietary
test automation tools and other open source solutions. Selenium-RC support for multiple
programming and scripting languages allows the test writer to build any logic they need into
their automated testing and to use a preferred programming or scripting language of one‘s
choice. Selenium-IDE allows for the addition of user-defined ―user-extensions‖ for creating
additional commands customized to the user‘s needs. Also, it is possible to re-configure how
the Selenium-IDE generates its Selenium-RC code. This allows users to customize the
generated code to fit in with their own test frameworks. Finally, Selenium is an Open Source
project where code can be modified and enhancements can be submitted for contribution. .

Test Suites

A test suite is a collection of tests. Often one will run all the tests in a test suite as one
continuous batch-job. When using Selenium-IDE, test suites also can be defined using a
simple HTML file. The syntax again is simple. An HTML table defines a list of tests where
each row defines the filesystem path to each test. An example tells it all.

A file similar to this would allow running the tests all at once, one after another, from
the Selenium-IDE. Test suites can also be maintained when using Selenium-RC. This is done
via programming and can be done a number of ways. Commonly Junit is used to maintain a
test suite if one is using Selenium-RC with Java. Additionally, if C# is the chosen language,
Nunit could be employed. If using an interpreted language like Python with Selenium-RC
than some simple programming would be involved in setting up a test suite. Since the whole
reason for using Sel-RC is to make use of programming logic for your testing this usually
isn‘t a problem. Few typical Selenium commands.

open – opens a page using a URL.

click/clickAndWait – performs a click operation, and optionally waits for a new page to
load.

verifyTitle/assertTitle – verifies an expected page title.

verifyTextPresent – verifies expected text is somewhere on the page.

verifyElementPresent – verifies an expected UI element, as defined by its HTML tag, is
present on the page.

verifyText – verifies expected text and it‘s corresponding HTML tag are present on the page.
verifyTable – verifies a table‘s expected contents.

waitForPageToLoad – pauses execution until an expected new page loads. Called

automatically when clickAndWait is used.

waitForElementPresent – pauses execution until an expected UI element, as defined by its

HTML tag, is present on the page.

The below requirements have been automated -

1. Open the given e-commerce website

2. Select a product with quantity more than 1 and add to cart
3. Select a product and update the delivery date and add to cart
4. View cart and checkout as a guest
5. Fill in all the delivery and checkout details
6. Confirm order and check for the order confirmation message

Folder directory information -

 drivers - Chromedriver.exe file

 Reports - HTML-testrunner generated reports
 Screenshots - Saved test screenshots (png)
 Pages - Separate python files for every page in the website (POM)
 Test - Main file consisting of the test script
Exp. No.: Date:

DATA DRIVEN TESTING USING SELENIUM AND TESTNG

Data Driven Testing is a strategic approach that involves executing a set of test script
actions in a repetitive manner, each time utilizing distinct input values sourced from an
associated data repository. This technique enhances efficiency by decoupling the ‘test_case‘
code from the underlying ‘data_set,’ streamlining testing processes.
It is one of the widely-used automation testing best practices for verifying the behavior and
efficiency of tests when handling various types of input values. You can learn more about the
different testing methods by reading the article on TDD vs BDD: Choosing The Suitable
Framework.

Here are the popular external data feed or data sources in data driven testing:

MS Excel Sheets (.xls, .xlsx)

CSV Files (.csv)

XML Files (.xml)

MS Access Tables (.mdb)

The data feed or data source not only contains the input values used for Selenium
automation testing but can also be used for storing the expected test result and the output
test result. This can be useful in comparing the test execution result and storing the same
for referring to later stages.

Data Driven Framework in Selenium WebDriver

Data Driven Framework is a highly effective and widely utilized automation

testing framework that enables iterative development and testing. It follows the principles
of data-driven testing, allowing you to drive test cases and test suites using external data
feeds such as Excel Sheets (xls, xlsx), CSV files (csv), and more. By establishing a
connection with the external data source, the test script seamlessly performs the required
operations on the test data, ensuring efficient and accurate testing.
 Using the Data Driven Framework in Selenium WebDriver, the test data set is
separated from the test implementation, reducing the overall effort involved in
maintaining and updating the test code. Minimal changes in the business rules will require
changes in the test data set, with/without minimal (or no) changes in the test code.

Selenium WebDriver lets you perform automated cross browser testing on web
applications; however, it does not have the support to perform create, read, update, and
delete (CRUD) operations on external data feeds like Excel sheets, CSV files, and more.
This is where third-party APIs like Apache POI has to be used since it lets you access and
performs relevant operations on external data sources.

Data Driven Testing using @DataProvider

Data-driven testing can be carried out through TestNG using its @DataProvider
annotation. A method with @DataProvider annotation over it returns a 2D array of the object
where the rows determine the number of iterations and columns determine the number of
input parameters passed to the Test method with each iteration.
This annotation takes only the name of the data provider as its parameter which is used to
bind the data provider to the Test method. If no name is provided, the method name of the
data provider is taken as the data provider’s name.
@DataProvider(name = "nameOfDataProvider")

public Object[][] dataProviderMethodName() {

//Data generation or fetching logic from any external source

//returning 2d array of object

return new Object[][] {{"k1","r1",1},{"k2","r2",2}};

After the creation of data provider method, we can associate a Test method with data
provider using ‘dataProvider’ attribute of @Test annotation. For successful binding of data
provider with Test method, the number and data type of parameters of the test method must
match the ones returned by the data provider method.

@Test(dataProvider = "nameOfDataProvider")

public void sampleTest(String testData1, String testData2, int testData3) {

System.out.println(testData1 + " " + testData2 + " " + testData3);

Code Snippet for Data Driven Testing in TestNG

@DataProvider(name = "dataProvider1")

public Object[][] dataProviderMethod1() {

return new Object[][] {{"k1","r1"},{"k2","r2"},{"k3","r3"}};

//The test case will run 3 times with different set of values

@Test(dataProvider = "dataProvider1")

public void sampleTest(String str1, String str2) {

System.out.println(str1 + " " + str2);

The above test “sampleTest” will run 3 times with different set of test data –
{“k1″,”r1”},{“k2″,”r2”},{“k3″,”r3”} received from ‘dataProvider1’ dataProvider method.
 Exp. No.: Date:

BUILD PAGE OBJECT MODEL USING SELENIUM AND TESTNG

Page Object Model, also known as POM, is a design pattern in Selenium that creates an
object repository for storing all web elements. It helps reduce code duplication and improves
test case maintenance.
In Page Object Model, consider each web page of an application as a class file. Each class
file will contain only corresponding web page elements. Using these elements, testers can
perform operations on the website under test.

Advantages of Page Object Model

 Easy Maintenance: POM is useful when there is a change in a UI element or a change in

action. An example would be: a drop-down menu is changed to a radio button. In this case,
POM helps to identify the page or screen to be modified. As every screen will have different
Java files, this identification is necessary to make changes in the right files. This makes test
cases easy to maintain and reduces errors.
 Code Reusability: As already discussed, all screens are independent. By using POM, one can
use the test code for one screen, and reuse it in another test case. There is no need to rewrite
code, thus saving time and effort.

 Readability and Reliability of Scripts: When all screens have independent java files, one
can quickly identify actions performed on a particular screen by navigating through the java
file. If a change must be made to a specific code section, it can be efficiently done without
affecting other files.

The Page Object Model is an often used method for improving maintainability of Selenium
tests, to this setup. To do so, we need to accomplish the following steps:

 Create Page Objects representing pages of a web application that we want to test

 Create methods for these Page Objects that represent actions we want to perform
within the pages that they represent
  Create tests that perform these actions in the required order and performs checks that
make up the test scenario

 Run the tests as TestNG tests and inspect the results

Creating Page Objects for our test application

For this purpose, again I use the ParaBank demo application that can be found here. I’ve
narrowed the scope of my tests down to just three of the pages in this application: the login
page, the home page (where you end up after a successful login) and an error page (where
you land after a failed login attempt). As an example, this is the code for the login page:

package com.ontestautomation.seleniumtestngpom.pages;

import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;

public class LoginPage {

private WebDriver driver;

public LoginPage(WebDriver driver) {

this.driver = driver;

if(!driver.getTitle().equals("ParaBank | Welcome | Online Banking")) {

driver.get("http://parabank.parasoft.com");
}
}

public ErrorPage incorrectLogin(String username, String password) {

driver.findElement(By.name("username")).sendKeys(username);
driver.findElement(By.name("password")).sendKeys(password);
 driver.findElement(By.xpath("//input[@value='Log In']")).click();
return new ErrorPage(driver);
}

public HomePage correctLogin(String username, String password) {

driver.findElement(By.name("username")).sendKeys(username);
driver.findElement(By.name("password")).sendKeys(password);
driver.findElement(By.xpath("//input[@value='Log In']")).click();
return new HomePage(driver);
}
}

It contains a constructor that returns a new instance of the LoginPage object as well as two
methods that we can use in our tests: incorrectLogin, which sends us to the error page
and correctLogin, which sends us to the home page. Likewise, I’ve constructed Page Objects
for these two pages as well. A link to those implementations can be found at the end of this
post.

Note that this code snippet isn’t optimized for maintainability – I used direct references to
element properties rather than some sort of element-level abstraction, such as an Object
Repository.

Creating methods that perform actions on the Page Objects

You’ve seen these for the login page in the code sample above. I’ve included similar methods
for the other two pages. A good example can be seen in the implementation of the error page
Page Object:

package com.ontestautomation.seleniumtestngpom.pages;

import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;

public class ErrorPage {

 private WebDriver driver;

public ErrorPage(WebDriver driver) {

this.driver = driver;
}

public String getErrorText() {

return driver.findElement(By.className("error")).getText();
}
}

By implementing a getErrorText method to retrieve the error message that is displayed on the
error page, we can call this method in our actual test script. It is considered good practice to
separate the implementation of your Page Objects from the actual assertions that are
performed in your test script (separation of responsibilities). If you need to perform additional
checks, just add a method that returns the actual value displayed on the screen to the
associated page object and add assertions to the scripts where this check needs to be
performed.

Create tests that perform the required actions and execute the required checks

Now that we have created both the page objects and the methods that we want to use for the
checks in our test scripts, it’s time to create these test scripts. This is again pretty
straightforward, as this example shows (imports removed for brevity):

package com.ontest automation.seleniumtestngpom.tests;

public class TestNGPOM {

WebDriver driver;

@BeforeSuite
 public void setUp() {

driver = new FirefoxDriver();

driver.manage().timeouts().implicitlyWait(10, TimeUnit.SECONDS);
}

@Parameters({"username","incorrectpassword"})
@Test(description="Performs an unsuccessful login and checks the resulting error
message")
public void testLoginNOK(String username, String incorrectpassword) {

LoginPage lp = new LoginPage(driver);

ErrorPage ep = lp.incorrectLogin(username, incorrectpassword);
Assert.assertEquals(ep.getErrorText(), "The username and password could
not be verified.");
}

@AfterSuite
public void tearDown() {

driver.quit();
}
}

Note the use of the page objects and the check being performed using methods in these page
object implementations – in this case the getErrorText method in the error page page object.

As we have designed our tests as Selenium + TestNG tests, we also need to define
a testng.xml file that defines which tests we need to run and what parameter values the
parameterized testLoginOK test takes. Again, see my previous post for more details.

<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd" >

<suite name="My first TestNG test suite" verbose="1" >

 <parameter name="username" value="john"/>
<parameter name="password" value="demo"/>
<test name="Login tests">
<packages>
<package name="com.ontestautomation.seleniumtestngpom.tests" />
</packages>
</test>
</suite>

Run the tests as TestNG tests and inspect the results

Finally, we can run our tests again by right-clicking on the testng.xml file in the Package
Explorer and selecting ‘Run As > TestNG Suite’. After test execution has finished, the test
results will appear in the ‘Results of running suite’ tab in Eclipse. Again, please note that
using meaningful names for tests and test suites in the testng.xml file make these results much
easier to read and interpret.