DEV Community: GOKUL SRINIVASAN

Selenium Python Architecture & Significance of Python Virtual Environment with examples

GOKUL SRINIVASAN — Mon, 27 Jul 2026 13:10:10 +0000

Python Selenium Architecture uses Client - Server architecture which enables the automation of the real browser via code. Compared to other approaches, where the user would have to operate the JavaScript by simulating the input, Selenium instructs the browser in conventional manners. Every time the user initiates an HTTP request by Python, the browser can effortlessly read and proceed with the instructions.

The main components consist of

the user’s Python code
the Python bindings (library)
the browser-specific driver
the browser itself.

1. Your Code

In your code, you simply use Selenium to open up a browser instance and perform the desired actions:

from selenium import webdriver

from selenium.webdriver.common.by import By

options = webdriver.ChromeOptions()

driver = webdriver.Chrome(options=options)

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

element = driver.find_element(By.ID, "submit-button")

element.click()

The code above will open up a browser instance and submit the form on the page.

2. Python Bindings (Library)

The Python bindings (library) represent the pip package that you have installed on your machine. It serves to convert the Python functions into HTTP requests that the browser will read and perform. For instance, when you send the click() function via the driver instance, the binding will turn it into a JSON-encoded request that follows the WebDriver REST API standard. The tool is open-source and available on GitHub.

3. Browser Driver

Every browser has its specific driver, which is the reason why you have to install additional packages for using Python Selenium. They receive the HTTP requests from the Python bindings and execute the corresponding actions in the browser. In most cases, the drivers run as independent processes on the port 9515 and reply to the requests from Python. With Selenium 4+, the drivers are automatically detected and installed via the Selenium Manager. Therefore, you do not have to manually specify their location anymore.

4. Web Browser

The web browser represents the software that you want to automate with your Python code. Unlike other automation tools that require you to use their lightweight counterpart (e.g., Puppeteer for Chrome), Python Selenium allows you to directly control your browser of choice like Chrome driver for Chrome, GeckoDriver for Firefox , EdgeDriver for MS Edge. The drivers accept the HTTP requests from Python, process them, and reply with the corresponding response.

Overview

The main steps that occur when you are using Python Selenium:

The first command (webdriver.Chrome()) launches the ChromeDriver in a separate process
The next command (driver.get("https://example.com")) will send the POST request with URL to the driver
Upon receiving the request, the Chrome browser will open up the requested URL
Once the page has been loaded, the browser will notify the driver and return the response to your Python code
When you call the quit() command, the driver will send a final request to close the browser instance

WebDriver Protocols

In previous Selenium versions (3.x), the communication between Python code and the browser followed the JSON Wire Protocol. It was based on the HTTP requests/responses that the browser received and responded to. Fortunately, most of the legacy endpoints have been deprecated, and Selenium 4+ uses the modern W3C standard. It implies that there is no need for extra HTTP requests/responses anymore since the WebDriver and browsers speak directly to each other. In some cases, the WebSockets protocol is used to establish a two-way communication channel for faster execution. It is especially useful when executing JavaScript assertions.

Selenium Grid

When it comes to distributing tests across multiple browsers, you will want to consider Selenium Grid. It has a hub that receives the HTTP requests from your Python code and nodes that actually perform the tests and return the results. In other words, the hub is used as a central point for managing multiple nodes. These nodes can be located anywhere as long as they have internet access. Furthermore, you can set up different nodes in accordance with the required OS/browser/version combinations.

Significance of Python Environment Variable

A Python virtual environment is a self-contained directory that houses a specific Python project. This virtual environment encapsulates the project’s dependencies in an isolated space, separate from your main Python installation and from any other Python projects on your computer.

The goal of using a virtual environment is to allow each project to manage its unique package requirements without interference from other projects, thus simplifying dependency management and mitigating version conflicts.

If you don’t use a virtual environment, any package that you install using pip is installed globally on your system. Your system doesn't know the package belongs to a particular project; it just sees it as a library available to all projects.

This can quickly become a problem when different projects need different versions of the same package. Imagine you have one project that relies on Selenium version 3 and another project that needs Selenium version 4. If you install Selenium 4 globally, it might overwrite Selenium 3, breaking the first project.

A virtual environment solves this by providing each project with its own environment where packages are installed, and versions can be specific to each project’s needs without affecting any others.

When you create a virtual environment, Python generates a dedicated directory that contains:

A copy of the Python interpreter (often as a symlink to your system’s Python)
Its own instance of pip, the package installer
A dedicated location for installing packages (typically within a site-packages directory inside the virtual environment)
Configuration files that point to the base Python installation the virtual environment was created from

After creating the environment, any package you install with pip goes directly into this directory instead of your system’s global Python installation.

Activating the environment

Before you can use the packages within a virtual environment, you must activate it. Activating means changing your system’s environment so that calls to python and pip in your terminal now refer to the Python and pip executables inside your activated virtual environment.

Once activated, python in your terminal points to the virtual environment's Python interpreter, and any packages you pip install are installed only within the virtual environment, leaving your main system Python installation unaffected.

Installing packages within the virtual environment

When a virtual environment is active, the packages you install are completely isolated. They are stored within the virtual environment directory and do not appear in your global Python installation or any other project’s virtual environment. This allows different projects to install and use specific, even conflicting, versions of the same package.

Freezing the environment

You can create a requirements.txt file that lists every package and its specific version currently installed in your active virtual environment. This is invaluable for sharing your project with others or for automated build and deployment systems, as it guarantees that the same set of dependencies can be recreated accurately in another environment later on. You can install all the listed packages with:

``bash

pip install -r requirements.txt

Deactivating the environment

When you’re finished working with a project and its virtual environment, you can deactivate it by simply typing:

`bash

deactivate

This switches your terminal back to using the system’s Python installation, and any further pip install commands will be directed to the global environment.

Examples for Python Virtual Environment

Creating the environment

`bash python -m venv venv `

Folder structure created

`plaintext venv/ ├── bin/ # (Scripts/ on Windows) ├── lib/ └── pyvenv.cfg `

Activation (macOS/Linux)

`bash source venv/bin/activate `

Activation (Windows - Command Prompt)

`bash venv\Scripts\activate.bat `

Activation (Windows - PowerShell)

`bash venv\Scripts\Activate.ps1 `

Installing dependencies inside it

`bash (venv) $ pip install selenium (venv) $ pip install pytest `

Freezing dependencies

`bash (venv) $ pip freeze > requirements.txt `

Resulting requirements file

`properties selenium==4.21.0 pytest==8.2.0 `

Reproducing the environment elsewhere

`bash python -m venv venv source venv/bin/activate pip install -r requirements.txt `

Deactivating

`bash (venv) $ deactivate `

What is Selenium? Why do we use Selenium for Automation?What is the relevance of Selenium in automation testing using Python?

GOKUL SRINIVASAN — Mon, 27 Jul 2026 05:08:20 +0000

What is Selenium?

Selenium is an open-source tool that lets you automate pretty much anything a real person would do in a web browser. Instead of just looking at web pages as static files, Selenium actually drives a real browser—Chrome, Firefox, Safari, Edge—and clicks, fills out forms, scrolls, and checks content just like you would.

Highlights:

Selenium WebDriver: This is the heart of Selenium. It talks directly to the browser through drivers like ChromeDriver or GeckoDriver and controls everything.
Selenium Grid: With Grid, you can run tests simultaneously across different machines, operating systems, and browsers. It’s perfect if you need to test a lot, fast.
Selenium IDE: This is a browser extension that makes things easy. You can record your actions and play them back—no heavy coding needed.

Why do we use Selenium for Automation?

Manual web testing gets old fast. Logging into the same app, clicking through endless menus, checking outputs after every little code change—it all eats up time, costs money, and mistakes creep in easily. That’s where Selenium steps in. It takes care of those tedious, repetitive actions automatically.

First, it’s open-source and free. You won’t deal with hefty licensing costs like you do with some big-name QA tools. Plus, you write a test script once and use it everywhere—Windows, Mac, Linux, any major browser like Chrome, Firefox, Edge, or Safari. You aren’t boxed into a single programming language, either. Selenium works comfortably with Python, Java, C#, JavaScript, Ruby, and more.

Selenium slides right into modern workflows, too. It connects smoothly with CI/CD tools like Jenkins, GitHub Actions, and Docker, so your automated tests run every time you push new code. That means faster feedback, fewer bugs, and way less hassle.

*What is the relevance of Selenium in automation testing using Python?
*
Selenium works with a bunch of programming languages, but pairing it with Python has really taken off in the QA and SDET worlds.

Here’s how it all fits together: You write your test script in Python (using something like pytest or unittest), hand it off to Selenium WebDriver, and that controls whichever browser you’re testing—Chrome, Firefox, you name it.

First off, Python’s syntax is clean and straightforward. You don’t get bogged down in extra code like you do with Java or C#. It’s a lot faster to write tests, and just as easy to keep them organized as your project grows.

Then there’s pytest. The whole testing ecosystem in Python is strong, but pytest makes things like test discovery, assertions, and running the same test with dozens of data sets incredibly simple. Need a nice HTML report? That’s covered too.

Python is more useful when we need to work with data. We can use it to read mock data from a CSV Or maybe pull info from a database or check JSON responses. Tools like pandas and requests handle all the above actions smoothly.

Python + Selenium isn’t just for testing. Teams often use it to scrape dynamic web pages—stuff that regular HTTP libraries can’t handle because of all the JavaScript. So you get both automation and the ability to grab hard-to-reach web content in one shot.

Common Manual Testing Technique

GOKUL SRINIVASAN — Tue, 19 May 2026 06:19:33 +0000

Software testing is a critical phase in the software development lifecycle, ensuring that the application functions as expected before it is delivered to the end user. Among the various approaches available, manual testing techniques remain fundamental to producing reliable and high quality software. The three most commonly used manual testing techniques are Black Box Testing, White Box Testing, and Experience Based Testing. Each of these techniques serves a distinct purpose and is applied at different stages of the testing process.

Black Box Testing

The first technique is Black Box Testing. As the name suggests, the tester has no knowledge of the internal code. They interact with the application through the console or UI by providing inputs and then validating the scenario based on the output received. This technique focuses entirely on the functional behavior of the application, making it highly effective for validating whether the system meets the specified requirements. Since the tester approaches the application from the perspective of an end user, it helps uncover defects that may impact the overall user experience.

Black box testing is further divided into the following sub-techniques:

Equivalence Partitioning — The input data is divided into partitions, where a single representative input from each group is used to test the scenario. This approach reduces the number of test cases required while still ensuring adequate coverage. By grouping similar inputs together and testing one from each group, testers can efficiently identify whether the application handles different categories of input correctly without the need to test every possible value.
Boundary Value Analysis — This technique is applied when functionality depends on a range of values. The tester validates the behavior at the start and end values of each range to ensure the boundary conditions are handled correctly. Defects in software are most commonly found at the edges of input ranges rather than at the center, making this technique particularly effective. By focusing on the minimum and maximum values of each range, testers can identify issues that may not be caught through general input testing.
Decision Table Technique — All business rules are listed out in a structured table, and each rule is systematically checked and validated against the defined business logic. This technique is especially useful when the application involves complex business rules with multiple conditions and corresponding actions. The decision table provides a clear and organized way to ensure that every possible combination of conditions has been accounted for and tested thoroughly.

White Box Testing

The second technique is White Box Testing. In this approach, the tester has full knowledge of the internal code and all the logic implemented within it. Unlike black box testing, this technique requires the tester to have a strong understanding of programming and system architecture. It focuses on the internal workings of the application, ensuring that the code is structured correctly and that all logical paths function as intended. It is further divided into the following sub-techniques:

Statement Coverage — The tester ensures that every statement within the code is executed at least once during testing. This is considered the most basic form of white box testing and serves as a foundation for ensuring that no part of the code is left untested. By achieving full statement coverage, testers can identify dead code or unreachable statements that may indicate a logic error.
Branch Coverage — Where multiple conditions exist within the code, the tester provides inputs that navigate through both the true and false outcomes, ensuring that all branches of the code are covered. This is a more thorough approach than statement coverage, as it accounts for every possible decision point within the code. Ensuring full branch coverage helps identify scenarios where certain conditions may not be handled correctly by the application.
Path Coverage — The tester ensures that every possible path through the code has been executed and thoroughly tested. This is the most comprehensive form of white box testing, as it considers every combination of branches and conditions within the code. While achieving full path coverage can be time consuming, it provides the highest level of assurance that the code is functioning correctly under all possible scenarios.

Experience Based Testing

The third technique is Experience Based Testing. This approach relies on the tester's knowledge and expertise accumulated over years of working in the field. Unlike black box and white box testing, this technique does not follow a strictly defined process. Instead, it leverages the tester's intuition, domain knowledge, and understanding of common defect patterns to guide the testing effort. It consists of three methods:

Exploratory Testing — Within a defined time frame, the tester freely explores all functionalities of the application, examining them in an unscripted and investigative manner. This method encourages creative thinking and allows the tester to simultaneously design and execute test cases based on what they discover during the session. It is particularly effective in the early stages of testing or when documentation is limited, as it does not rely on predefined test cases.
Error Guessing — This method is driven purely by the tester's experience from previous releases. The tester draws on their understanding of areas where developers are likely to introduce mistakes and identifies functionalities that have historically been prone to defects, using this insight to guide their testing. While it may appear informal, error guessing can be highly effective when carried out by an experienced tester who has a deep understanding of the application and its development history.
Checklist Based Testing — A structured checklist is prepared covering all key functionalities, and the tester methodically follows this checklist to ensure that every item is validated. This method strikes a balance between structure and flexibility, providing the tester with a clear set of items to verify while still allowing room for judgment during execution. Checklists are often built up over time based on past testing experiences and known problem areas, making them a valuable resource for ensuring consistent test coverage.

*Manual Testing is being transformed in the ages of AI *

With the rise of AI, many question whether manual testing is still relevant. AI can generate test cases, execute repetitive scenarios, and identify defects faster. However, manual testing remains indispensable in areas such as exploratory testing, user experience validation, and complex business scenario testing, where human judgment and intuition are essential. Experienced testers bring contextual understanding that AI cannot fully replicate. Rather than replacing manual testers, AI serves as a complement, handling repetitive tasks while testers focus on areas requiring critical thinking. Together, they ensure the delivery of high quality software.