DEV Community: Gayathri

🧪 Selenium with Python: A Practical Cheat Sheet for Modern Test Automation

Gayathri — Fri, 24 Apr 2026 23:13:16 +0000

If you’re a QA engineer stepping into automation — or an SDET who just needs a quick refresher — this cheat sheet covers the Selenium + Python essentials you actually use at work.

No theory overload. No outdated patterns. Just practical examples you can copy, adapt, and scale.

Thanks for reading! Subscribe for free to receive new posts and support my work.

✅ Setup & Installation

Install Selenium:

pip install selenium

Make sure the correct browser driver is available in your system PATH:

Chrome → chromedriver

Firefox → geckodriver

Edge → msedgedriver

🚀 Starting the Browser

Launch Chrome
from selenium import webdriver

driver = webdriver.Chrome()

driver.get(”https://example.com”)

Headless Mode (Recommended for CI)

from selenium.webdriver.chrome.options import Options

options = Options()

options.add_argument(”--headless”)

options.add_argument(”--window-size=1920,1080”)

driver = webdriver.Chrome(options=options)

🔍 Locating Elements (The Most Important Skill)

Always prioritize reliable, stable locators.

from selenium.webdriver.common.by import By

Preferred Locators
driver.find_element(By.ID, “submit”)

driver.find_element(By.NAME, “email”)

driver.find_element(By.CSS_SELECTOR, “.login-button”)

driver.find_element(By.CSS_SELECTOR, “input[type=’password’]”)

XPath (Use Sparingly)

driver.find_element(By.XPATH, “//button[text()=’Login’]”)

✅ Tip: If your tests break often, your locators are probably the problem.

✍️ User Interactions

element.click()
element.send_keys(”user@test.com”)
element.clear()
Read values:
element.text
element.get_attribute(”value”)

⏳ Waiting for Elements (Non‑Negotiable)

Explicit Waits (Best Practice)
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
wait = WebDriverWait(driver, 10)
login_btn = wait.until(
EC.element_to_be_clickable((By.ID, “login”))
)

Common conditions:

EC.presence_of_element_located
EC.visibility_of_element_located
EC.element_to_be_clickable

❌ Avoid time.sleep() — it causes flaky tests.

📄 Forms & Dropdowns

from selenium.webdriver.support.ui import Select
dropdown = Select(driver.find_element(By.ID, “country”))
dropdown.select_by_visible_text(”India”)

🔔 Alerts, Frames & Windows

Alerts

alert = driver.switch_to.alert
alert.accept()

iFrames

driver.switch_to.frame(”frameName”)
driver.switch_to.default_content()

Multiple Tabs
driver.switch_to.window(driver.window_handles[1])

📜 Scrolling & JavaScript

driver.execute_script(”window.scrollTo(0, document.body.scrollHeight)”)
driver.execute_script(”arguments[0].scrollIntoView()”, element)

📷 Screenshots (For Failing Tests)

driver.save_screenshot(”failure.png”)
element.screenshot(”button.png”)

🧹 Cleanup
driver.close()
driver.quit()

🚀 Selenium + Pytest: Real‑World Automation Setup
Selenium alone isn’t enough. Pytest makes your automation scalable, readable, and CI‑ready.
**
✅ Install Pytest**

pip install pytest

🧱 Project Structure (Recommended)
tests/
├── pages/
│ └── login_page.py
├── conftest.py
├── test_login.py
└── pytest.ini

🔁 Pytest WebDriver Fixture

conftest.py
import pytest
from selenium import webdriver

@pytest.fixture
def driver():
driver = webdriver.Chrome()
driver.maximize_window()
yield driver
driver.quit()

✅ Automatically manages setup & teardown
✅ Cleaner than setUp() / tearDown()

🧪 Writing a Test

def test_valid_login(driver):
driver.get(”https://example.com/login”)
driver.find_element(By.ID, “username”).send_keys(”admin”)
driver.find_element(By.ID, “password”).send_keys(”password”)
driver.find_element(By.ID, “login”).click()
assert “Dashboard” in driver.title

🧠 Using Page Object Model with Pytest

pages/login_page.py

class LoginPage:
def init(self, driver):
self.driver = driver
def login(self, user, pwd):
self.driver.find_element(By.ID, “username”).send_keys(user)
self.driver.find_element(By.ID, “password”).send_keys(pwd)
self.driver.find_element(By.ID, “login”).click()

test_login.py

def test_login_success(driver):
page = LoginPage(driver)
page.login(”admin”, “password”)
assert “Dashboard” in driver.title

🏷️ Pytest Markers (Power Feature)

@pytest.mark.smoke
def test_smoke_login():
pass

Run specific tests:

pytest -m smoke

📊 HTML Reports (CI‑Friendly)

pip install pytest-html
pytest --html=report.html

Why Pass/Fail CI Pipelines Break Down—and How Risk‑Based Quality Gates Fix It

Gayathri — Mon, 13 Apr 2026 16:40:45 +0000

Most CI/CD pipelines still make release decisions using a binary model:

✅ Tests passed → deploy
❌ Tests failed → block

That model works well for small systems.

It breaks down quickly in large, regulated, or business‑critical environments.

In practice, not all failures carry the same risk.

A flaky UI test failing in reporting is not equivalent to a severe failure in payments or authentication—but traditional pipelines treat them as equals.

This post explains why binary quality gates fail in real systems, and introduces a risk‑based quality gate approach that better matches how experienced engineering teams actually make release decisions.

The Problem with Pass/Fail Gates
Binary quality gates assume:

All failures are equal
More failures = higher risk
Zero failures = safe to deploy

In enterprise environments, those assumptions stop being true.
Real release decisions depend on:

Severity of failures
Business criticality of the affected areas
Concentration of risk, not just raw counts
Context that automation alone cannot infer

As a result, teams often:

Override automated blocks
Ignore noisy alerts
Lose trust in pipeline decisions altogether

When automation is frequently bypassed, it stops being a safety mechanism and becomes background noise.

Release Readiness Is a Decision Problem
At scale, release readiness is not just a testing problem.
It is a decision problem under uncertainty.
Experienced release teams rarely ask:

“Did tests fail?”

They ask:

*“Where is the risk, how severe is it, and does this warrant human review?”
*
To reflect that reality, release decisions need at least three outcomes, not two:

✅ GO — acceptable risk
⚠️ CAUTION — elevated risk, human review required
❌ STOP — unacceptable risk

The middle state matters. It’s where judgment, accountability, and governance live.

A Risk‑Based Quality Gate Model
Instead of failing fast on any error, a risk‑based quality gate:

Ingests test results as pipeline artifacts
Assigns weights based on severity and functional area
Aggregates risk across all failures
Produces a clear GO / CAUTION / STOP decision

Crucially, it also explains that decision.
This avoids:

Over‑blocking on low‑impact failures
Silent auto‑approval of risky releases
Encoding business nuance into brittle rules

Example: Explainable High‑Risk Release Decision
Using a CLI‑based quality gate against the following input:
examples/high_risk_release.json

The pipeline produces:
Release Risk Score: 125
Decision: STOP
Reason: High aggregated risk score across critical areas
Recommended Action: Block deployment pending investigation

This output makes three things explicit:

Why the release is blocked
Where risk is concentrated
What action is expected next

The goal isn’t to replace human judgment—but to support it with transparent evidence.

Why This Works Better Than Binary Gates
A risk‑based approach improves:

Trust in automation
The system knows when it cannot decide alone.

Governance and auditability
Decisions are explainable, not opaque.

Signal‑to‑noise ratio
Low‑impact failures stop dominating release discussions.

Alignment with real decision‑making
The pipeline reflects how senior engineers actually think.

Reference Implementation
A lightweight, CLI‑based reference implementation of this model is available here:
👉 Risk‑Based Quality Gate (v1.0.0)
https://github.com/gaya3bollineni/risk-based-quality-gate/releases/tag/v1.0.0
The project is intentionally minimal:

No CI plugins
No dashboards
No ML or heuristics

It is designed to be run inside a CI/CD pipeline as a decision‑support step, not as an opaque enforcement mechanism.

Final Thought
If your pipeline frequently asks humans to override its decisions, the automation isn’t failing—the decision model is.
Risk‑based quality gates acknowledge uncertainty, surface context, and formalize the handoff between automation and human accountability.
That’s not adding complexity.
It’s matching reality.

Why Binary CI/CD Quality Gates Fail at Scale (and a Risk-Based Alternative)

Gayathri — Mon, 06 Apr 2026 19:52:21 +0000

Introduction

Most CI/CD pipelines rely on binary quality gates:
tests pass or fail, coverage meets a threshold or it doesn’t, vulnerabilities are present or not.

That model works well for small systems.

It starts to break down as systems grow larger, more distributed, and more regulated.

In real-world enterprise environments, not all failures carry the same risk — yet CI pipelines often treat them as if they do.

The Reality in Large and Regulated Systems

In domains like insurance, healthcare, or finance, software systems support:

Critical business workflows
Regulatory and compliance requirements
Long-lived platforms with varying levels of technical debt

A test failure in a non-critical reporting workflow does not introduce the same level of risk as a failure in a claims-processing or patient-safety flow.

Yet traditional quality gates evaluate both the same way.

The result is usually one of two outcomes:

Teams bypass gates to maintain delivery speed
Pipelines block releases even when the actual risk is low

Neither outcome improves software quality.

Why Binary Gates Are a Poor Proxy for Risk

Binary gates assume:

All failures are equal
All changes carry the same impact
Risk can be represented by a single threshold

In practice, experienced engineers already reason about releases differently:

Where did failures occur?
How severe are they?
How concentrated is the risk?
Does this change affect regulated or business‑critical paths?

CI/CD pipelines usually lack a way to express this reasoning.

A Risk-Based Alternative

A risk-based quality gate shifts the decision model from pass/fail to contextual evaluation.

Instead of enforcing a single blocking rule, it:

Aggregates multiple quality signals
Applies severity and domain weighting
Produces human‑interpretable outcomes

For example:

✅ GO – acceptable level of release risk
⚠️ CAUTION – elevated risk, review recommended
❌ STOP – high risk, release should be blocked

This mirrors how release decisions are actually made by senior engineers — but in an automated, explainable way.

CI/CD as a Decision System

Thinking of CI/CD as a decision system (rather than a checklist) changes what quality gates represent.

The pipeline’s role becomes:

Assessing risk, not perfection
Supporting informed decisions, not blind enforcement
Making trade-offs explicit and auditable

Risk-based gates don’t lower quality standards — they make quality signals more actionable.

A Lightweight Open Source Reference

To explore this idea practically, I open-sourced a lightweight reference implementation of a risk-based quality gate designed for CI/CD pipelines:

👉 https://github.com/gaya3bollineni/risk-based-quality-gate

It demonstrates how test results can be evaluated using severity and risk concentration to produce clear GO / CAUTION / STOP outcomes instead of binary failures.

The goal is not to replace existing tools, but to provide a simple, extensible foundation for risk-aware release gating.

Closing Thoughts

Binary quality gates made sense when systems were smaller and simpler.

At scale, especially in regulated or business-critical environments, release decisions require nuance.

Risk-based quality gates offer a way to bring that nuance into CI/CD pipelines while keeping decisions transparent and automated.

If quality gates are meant to help teams ship better software, they should reflect how risk is actually evaluated in practice.