MODULE – 5

Advanced Testing & Selenium

[Link]
CSS Locators

 CSS locators are used in Selenium to find web elements using CSS
rulesFaster than Xpath
 Faster and more efficient than Xpath
 Supported in all modern browsers
 Supports IDs, classes, attributes

[Link]
Why Use CSS Locators?
Faster execution compared to XPath
Clean and readable syntax
Can target elements using IDs, classes, attributes, structure
Works well for CSS-based web applications
Common CSS Selector Patterns

a) ID Selector
Fastest because IDs are unique
b) Class Selector
.btn-primary
Selects elements with given class name
c) Tag Selector
input
Selects all elements of that tag

[Link]
Common CSS Selector Patterns

d) Tag + Class
[Link]-control

e) Attribute Selector
input[type='email']
Very useful for precise matching

f) Contains / Starts-with / Ends-with

Contains → input[name*='user']
Starts with → input[name^='user']
Ends with → input[name$='name']

[Link]
Examples for Real Use

Login button: button#loginBtn

Username input: input[name='username']
Search box: input[type='search']
Add to cart: [Link]-to-cart

Advanced Selectors

Combine class + attribute → [Link][type='submit']

Multiple classes → .[Link]
Sibling selector → label + input

[Link]
Understanding CSS Locators
CSS locators are one of the most powerful and efficient ways to identify web elements in Selenium. They offer faster execution than XPath in
most browsers and provide a clean, readable syntax that makes your test code easier to maintain. Mastering CSS selectors is fundamental to
writing robust, reliable automated tests.

ID Selector Class Selector

#elementId .className

The most specific and fastest selector. Always prefer ID when Select elements by their CSS class. Can match multiple elements if
available as it uniquely identifies an element. the class is used in multiple places.

Example: #loginButton Example: .submit-btn

Attribute Selector Tag Selector

[attribute='value'] tagname

Target elements based on any HTML attribute like name, type, or Select all elements of a specific type. Usually combined with other
custom data attributes. selectors for precision.

Example: [name='username'] Example: input[type='text']

CSS selectors can be combined and chained to create highly specific locators. For instance, [Link] > input#username selects an input
with ID "username" that is a direct child of a div with class "container". This hierarchical approach helps you pinpoint exactly the element you
need, even in complex DOM structures.
[Link]
Selenium WebDriver
 Automates browser actions
 Supports multiple languages
 Cross-browser support
 What is Selenium WebDriver?
 A tool used to automate web applications
 Controls the browser like a real user
 Part of the Selenium suite (IDE, WebDriver, Grid)

[Link]
Why use WebDriver?

Supports multiple browsers (Chrome, Firefox, Edge, Safari)

Works with many languages: Java, Python, C#, JavaScript
Allows full end-to-end testing of web apps
Fast, flexible, open-source

How Selenium WebDriver Works

Your test script sends commands

WebDriver passes commands to the browser driver
Browser performs the action (click, type, open page)
Browser returns response to WebDriver

[Link]
Basic WebDriver Operations:

Open browser
Navigate to URL
Find elements using locators
Click / Type / Select
Get text / Validate output
Close browser

Common Methods

get() → open URL

findElement() → locate an element
click() → click button
sendKeys() → type text
getText() → read output
close() → close current tab
quit() → close entire browser

[Link]
End-to-End Automation
 Automate complete user flows
 Use locators + waits
 Validate outputs and behavior

Steps in End-to-End Automation

a) Launch Browser
 Open Chrome/Firefox using WebDriver
 Navigate to the target URL

b) Login (if required)

 Enter username
 Enter password
 Click Login button
[Link]
Steps in End-to-End Automation

c) Perform Main Actions

 Search items
 Fill forms
 Add products to cart
 Upload documents
 Navigate pages

d) Validate Output
 Check if results are correct
 Verify success messages
 Confirm correct redirection
 Ensure expected behavior

[Link]
Steps in End-to-End Automation
 e) Logout / Close Browser
 Log out safely
 Close or quit the browser after testing

[Link]
Identifying CSS & XPath
 Use browser dev tools
 Inspect elements and attributes
 Generate robust selectors

[Link]
Identifying CSS Locators & XPath in Chrome and Firefox
1. Using Chrome Developer Tools
 Open the webpage
 Right-click the element → Inspect
 Chrome DevTools opens with the element highlighted
 You can find attributes like:
 id
 class
 name
 type
 placeholder
 custom attributes

[Link]
2. Using Firefox Developer Tools

 Right-click element → Inspect

 Firefox Inspector shows element attributes
 Check id, class, and attribute values
 To copy locators in Firefox:
 Right-click element in Inspector
 Copy → CSS Selector
 Copy → XPath

[Link]
3. Generating CSS Locators (Manually)
a) By ID
 #username

b) By Class
 .login-btn

c) By Attribute
 input[type='email']

d) Contains / Starts-with / Ends-with

 input[name*='user']
 input[name^='log']
 input[name$='name']

[Link]
 e) Parent → Child

 div > input

5. Tips for Writing Good Locators
 Prefer ID → most stable

 Avoid absolute XPath (starts with /html/body/...)

 Use CSS selectors when possible → faster

 Use unique attributes
 Avoid auto-generated class names (React/Angular apps)

[Link]
Custom XPath
 Use attributes to build unique XPath
 Avoid brittle absolute paths
 Prefer relative XPath

[Link]
Agile Testing
 Continuous testing
 Collaboration between teams
 Align with user stories

[Link]
The Agile Testing Quadrants
The Agile Testing Quadrants provide a framework for understanding different types of testing and when to apply them. These quadrants help teams plan
comprehensive testing strategies that balance technology-facing and business-facing tests, as well as tests that support the team versus those that
critique the product.
Q1: Technology-Facing, Support Team Q2: Business-Facing, Support Team
Unit Tests & Component Tests Functional & Story Tests

• Automated tests created by developers • Automated acceptance tests

• Test individual functions and classes • Validate user stories and scenarios
• Run in milliseconds, thousands per build • Examples: Selenium tests, API tests
• Foundation of test automation pyramid • Ensure features work as intended

Q4: Technology-Facing, Critique Product Q3: Business-Facing, Critique Product

Non-Functional Tests Exploratory & Usability Testing

• Performance and load testing • Manual testing to discover issues

• Security testing • User experience evaluation
• Compatibility testing • Beta testing, UAT
• Ensure system meets quality attributes • Find unexpected behaviors

Effective Agile testing requires balance across all four quadrants. Teams often over-focus on Q2 (functional tests) while neglecting Q1 (unit tests) and Q4
(non-functional tests). A healthy test strategy addresses all quadrants appropriately for your context.

[Link]
Types of Testing
 Smoke Testing
 Exploratory Testing
 Compatibility Testing
 Database Testing
 Security Testing
 UAT
 Ad-hoc Testing
 API Testing

[Link]
What is Smoke Testing?

• A quick, basic test performed on a new

build
• Checks whether the major and critical
functionalities are working
• Ensures the build is stable enough for
further testing

Why is it called “Smoke”?

Comes from hardware testing:

If a device is powered on and no smoke
comes out, it’s safe to test further.
Same idea in software:
If the build doesn’t break immediately, QA
can continue testing.

[Link]
3. Purpose of Smoke Testing

To verify if the application’s core functions are working

To ensure the build is ready for detailed testing
To catch major defects early

4. When is Smoke Testing Performed?

After receiving a new build from developers

Before starting Regression Testing
Before pushing code to QA / UAT environments

[Link]
5. What Does Smoke Testing Cover?
Only critical and high-level features
Example checks:
Application opens without errors
Login works
Dashboard loads
Main navigation works

6. Benefits of Smoke Testing

Saves time by catching build-breaking issues early
Prevents QA from wasting time on unstable builds
Improves communication between Dev and QA
Quick to execute (5–20 minutes)

[Link]
7. Example

Scenario: E-commerce App

Smoke test may include:

Launch website
Login
Search for a product
Add to cart
Logout
If these work → Build is stable.

[Link]
Exploratory Testing

A testing approach where testers explore the application freely

No strict test cases → testers use their experience, intuition, and creativity
Testing and learning happen at the same time

2. Key Idea
“Think and Test” at the same time
Tester decides what to test next based on results
Very useful to find unexpected defects

3. When Exploratory Testing is Used

When requirements are unclear

When there is less time for structured testing
For testing new features
For critical, complex, or high-risk areas
After bug fixes to find side effects

[Link]
4. Characteristics of Exploratory Testing
No pre-written test cases
Tester uses domain knowledge
Focuses on discovering hidden bugs
Encourages creativity
Tests real user behavior and edge cases

5. Advantages
Quickly finds critical, hard-to-detect bugs
Saves time in fast development cycles
Helps understand the application better
Encourages tester skill and intuition

6. Limitations
Cannot be used for formal documentation
Hard to repeat exactly (unless notes are taken)
Depends on tester’s experience level

[Link]
7. Example

For a shopping app, an exploratory tester may try:

Adding products rapidly
Removing items repeatedly
Applying different filters
Logging in/out many times
Trying invalid inputs
Testing random sequences of actions
Often these find bugs that scripted tests miss.

[Link]
Compatibility Testing

A type of non-functional testing

Ensures the application works correctly across different environments
Checks how well the software performs with various devices, browsers, OS, networks,
etc.

2. Why is Compatibility Testing Important?

Users access applications from different platforms
Prevents issues like:
UI breaking
Layout shifting
Features not working
Performance differences
Ensures a consistent user experience for everyone

[Link]
3. Types of Compatibility Testing

a) Browser Compatibility
Test app on different browsers:
Chrome
Firefox
Edge
Safari
b) OS Compatibility
Windows
macOS
Linux
Android
iOS

[Link]
3. Types of Compatibility Testing

c) Device Compatibility
Mobile
Desktop
Tablet
Different screen sizes/resolutions
d) Network Compatibility
2G, 3G, 4G, 5G
Slow networks
Wi-Fi, Ethernet
e) Software Compatibility
Different versions of:
.NET
Java
Databases
Browsers

[Link]
4. What Do Testers Check?

Layout and UI alignment

Buttons, forms, menus working properly
Performance & loading speed
Font rendering
Images and videos loading correctly
Cross-browser behavior (CSS, JS)

5. Tools for Compatibility Testing

BrowserStack
Sauce Labs
LambdaTest
CrossBrowserTesting

[Link]
6. Example
Scenario: Online Shopping Website
Test on:
Chrome (latest & older version)
Firefox (desktop & mobile view)
Safari on iPhone
4G mobile network
Check if all pages, cart, login, payment work the same everywhere.

[Link]
Database Testing

Testing the backend (database) of an application

Ensures data storage, retrieval, update, and deletion work correctly
Verifies that the database is consistent, accurate, and reliable

Why Do We Test Databases?

To ensure data is saved correctly

To prevent data loss or corruption
To check if frontend actions update the backend properly
To validate business rules at the database level
Example: When a user registers → details must be stored correctly in the DB.

[Link]
3. What Do We Test in Database Testing?

a) Data Validation
Check if data saved in database matches user input
Example: Order amount, username, email, etc.

b) Data Integrity
Ensuring relationships work:
Primary keys
Foreign keys
Unique constraints

c) CRUD Operations
Create
Read
Update
Delete
All should work properly

[Link]
d) Stored Procedures & Functions
Check if SQL procedures execute correctly
Verify input/output parameters

e) Triggers
Ensure triggers fire correctly during insert/update/delete

4. How Database Testing Is Done

Using SQL queries
Compare expected data vs actual data
Validate tables, columns, constraints

Tools used:
SQL Server Management Studio (SSMS)
Oracle SQL Developer
MySQL Workbench

[Link]
Security Testing –

1. Protects the application from threats

Ensures the system is safe from hacking, attacks, and misuse.

2. Checks authentication & authorization

Verifies login security and access permissions.

3. Prevents data leaks

Ensures sensitive data (passwords, personal info) is protected.

4. Identifies vulnerabilities
Finds issues like SQL injection, XSS, broken access control, etc.

5. Ensures compliance & safe user experience

Makes the application secure, reliable, and trustworthy for users.

[Link]
UAT (User Acceptance Testing)

Performed by end users or clients to validate the product.

Ensures the software meets business needs and real-world usage.

Done after system testing and before final release.

Uses real-life scenarios to test user workflows.

Confirms the application is ready for production.

If UAT passes → client approves/go-live; if not → changes required.

[Link]
Ad-hoc Testing –

Unplanned, informal testing done without test cases.

Tester freely checks the application using intuition and experience.

Mainly used to find unexpected or hidden defects.

Performed when time is limited.

No documentation — test cases are not written.

Very useful for testing new or complex areas quickly.

[Link]
 UAT vs Ad-hoc Testing — Comparison Table

Feature UAT (User Acceptance Testing) Ad-hoc Testing

Purpose Validate business requirements Find unexpected/hidden defects
Performed By End users / Clients Testers
Planning Well-planned, structured No planning, informal
Test Cases Uses predefined test cases No test cases used
After system testing, before
When Performed Anytime during testing
release
Documentation Documented scenarios & results No documentation
Outcome Client approval for Go-Live Identify defects quickly

[Link]
Test Scenarios & Test Cases
 Define clear scenarios
 Map user journeys
 Write detailed test cases

[Link]
Test Scenarios & Test Cases – Example App:

Login + Search + Add to Cart (E-commerce)

TEST SCENARIOS (High-Level)

Scenario 1: User Login

Verify user can open the login page

Verify user can enter username & password
Verify login with valid credentials
Verify error message for invalid login
Verify “Forgot Password” flow

[Link]
Scenario 2: Product Search

Verify search bar is visible

Verify searching with valid product name
Verify searching with invalid product name
Verify product list displays correct items
Verify filters/sorting work properly

Scenario 3: Add to Cart

Verify product details page opens

Verify “Add to Cart” button works
Verify item quantity can be increased/decreased
Verify cart total updates correctly
Verify user can remove item from cart

[Link]
Scenario 4: Logout

Verify logout option is available

Verify user is logged out successfully
Verify session is cleared after logout

[Link]
DETAILED TEST CASES (With Steps)

Test Case 1: Valid Login

Test Case ID: TC_LOGIN_01
Scenario: User Login
Precondition: User has valid credentials

Step No. Test Steps Test Data Expected Result

Open the application
1 — Login page should load
URL
Username should be
2 Enter valid username user@[Link]
accepted
Password should be
3 Enter valid password Pass@123
accepted
User should be
4 Click Login button — successfully logged in &
redirected to Homepage

[Link]
Test Case 2: Invalid Login

Test Case ID: TC_LOGIN_02

Step Test Steps Test Data Expected Result

1 Open login page — Page loads successfully
Error message should
2 Enter invalid username wrong@[Link]
display
Error message should
3 Enter invalid password wrong123
display
Invalid credentials
4 Click Login —
message shown

[Link]
Test Case 3: Product Search
Test Case ID: TC_SEARCH_01

Step Test Steps Test Data Expected Result

1 Go to search bar — Search bar visible
Suggestions should
2 Enter product name “Laptop”
appear
List of laptops should be
3 Click Search —
displayed

[Link]
Test Case 4: Add to Cart

Test Case ID: TC_CART_01

Step Test Steps Test Data Expected Result

1 Open product page Laptop Product details display
2 Click "Add to Cart" — Product added to cart
3 Check cart count — Cart count increases by 1
Total matches product
4 Verify total amount —
price

[Link]
Test Case 5: Logout

Test Case ID: TC_LOGOUT_01

Step Test Steps Expected Result

1 Click profile icon Menu opens
2 Click logout User logged out
3 Try accessing pages Should redirect to Login page

[Link]