Selenium Automation for QA Testers (No CI/CD Needed)

Introduction: Why Selenium Still Matters

In a world of flashy automation frameworks and CI/CD pipelines, Selenium continues to be a practical entry point for QA testers. Whether you’re transitioning from manual testing or expanding your skillset, Selenium gives you the power to automate browser interactions in a way that is both reliable and platform-independent. And the best part? You don’t need a CI/CD pipeline or a full-blown framework to get started.

To help you practice everything in this guide, we’ve set up a sample automation sandbox at playground.qajourney.net—a web app built specifically for QAJourney readers to run UI tests and get hands-on experience with real-world elements. This will be the test site we’ll use throughout the examples. and CI/CD pipelines, Selenium continues to be a practical entry point for QA testers. Whether you’re transitioning from manual testing or expanding your skillset, Selenium gives you the power to automate browser interactions in a way that is both reliable and platform-independent. And the best part? You don’t need a CI/CD pipeline or a full-blown framework to get started.

This guide is written for QA testers who want to begin automation testing with Selenium—without the pressure of mastering DevOps pipelines or reinventing their team’s entire test process.

If you’re learning QA automation or looking for a consistent place to practice test scenarios, the QA Testing Playground is built for you. It’s designed to simulate real-world UI behaviors while staying lightweight and inspectable.

Every test module featured in this project links directly to the QA Testing Playground at playground.qajourney.net — a live, inspectable sandbox built for real-world QA practice.

You can also explore the complete automation scripts inside the QAJourney Automation Lab GitHub repo at github.com/jarencudilla/qajourney-automation-lab, with ready-to-use examples for Selenium, Cypress, Playwright, and manual testing — all mapped to the same playground pages.

Setting Up Your Environment

Selenium works across several programming languages including Java, Python, C#, and JavaScript. If your background includes front-end testing or DOM manipulation, JavaScript with Selenium WebDriver (or WebDriverIO) offers the smoothest learning curve.

Minimum setup includes:

Selenium WebDriver (choose your language binding)
Browser driver (e.g., ChromeDriver, GeckoDriver for Firefox)
An IDE or code editor (like VS Code, IntelliJ, or Eclipse)
Sample test site or staging environment to practice on

You can write a basic script that opens a browser, clicks around, validates content, and closes—all without extra layers or dependencies.

Getting Started Without Code: Selenium IDE

When I first started exploring automation, Selenium IDE was my gateway. For a while, I thought that was all automation testing was—something like AutoHotkey or iMacros. It felt more like scripting macros than writing test cases. But even though it was basic, it opened my eyes to what automation could be. It gave me confidence, a visual way to understand locators, and just enough of a spark to start exploring real scripting with Selenium WebDriver.

If you’re not yet comfortable with scripting, Selenium IDE is a powerful browser extension that lets you record and replay interactions in the browser.

Where it works:

✅ Google Chrome (official extension)
✅ Mozilla Firefox (supported)
✅ Microsoft Edge (via Chrome extension support)

What it offers:

Record-click-type workflows directly in the browser
Export recorded tests to actual Selenium code
Add simple assertions and loops
Perfect for manual testers who want to dip their toes into automation without coding overhead

Writing Your First Selenium Script (JS Example)

For testers with JavaScript experience, here’s a basic Selenium WebDriver script in Node.js:

const { Builder, By, until } = require('selenium-webdriver');
(async function exampleTest() {
  let driver = await new Builder().forBrowser('chrome').build();
  try {
    await driver.get('https://playground.qajourney.net');
    await driver.findElement(By.css('h1')).getText();
  } finally {
    await driver.quit();
  }
})();

This script launches a browser, navigates to a site, grabs the header text, and quits—all in under 15 lines.

Choosing the Right Starting Path

Manual Tester? Start with Selenium IDE to record basic tests and export to code when you’re ready.
JavaScript-friendly? Use Node.js + Selenium or WebDriverIO for quick prototyping.
Python/Java comfortable? The Selenium docs offer solid examples for both languages.

Your goal at this stage isn’t to build a robust test suite—it’s to get familiar with element locators, page interactions, and browser behavior.

Tips for Success Without CI/CD

Just because you’re not hooked into Jenkins or GitHub Actions doesn’t mean your automation isn’t valuable.

Run tests locally or on demand for fast feedback
Organize scripts using folders or basic test runners (e.g., Mocha, JUnit)
Version your scripts with Git, even if not fully integrated
Focus on stability and repeatability, not volume

Common Beginner Pitfalls

Understanding how to locate elements is one of the most crucial parts of Selenium automation. You’ll commonly use either XPath or CSS selectors to identify elements, but they each have pros and cons:

XPath vs. CSS Selectors

The locator strategy you choose will also be affected by the way the front-end is built. Working with apps that use frameworks like Bootstrap, Tailwind CSS, or custom (often chaotic) styling can significantly impact test stability.

Bootstrap tends to offer more consistent and predictable class names and structures. This makes CSS selectors easier to use and often more resilient across releases.
Tailwind CSS uses utility-first class names that are often very long and non-semantic. While this is great for development speed, it can make locators noisy or fragile unless unique data attributes are used.
Custom Code—especially when poorly structured—can lead to what testers dread: spaghetti HTML. When divs are deeply nested, selectors are dynamic, or DOM elements are inserted programmatically, even the best XPath might break.

In such cases, collaborating with developers to include data-testid or stable id/class attributes can make a big difference. Don’t hesitate to advocate for testability in your team’s front-end review process.

Also, keep in mind that automation can be a huge asset when refactoring. It gives you confidence that features continue to work while front-end code is being reorganized or cleaned up. Make sure to coordinate with your UX designer and senior developer, especially when reviewing UI delivered by junior engineers. Sloppy markup can and often does sneak through code reviews—your automation scripts can serve as the safety net (and the reason to clean things up).

CSS Selectors
- ✅ Faster and more readable
- ✅ Supported across all modern browsers
- ✅ Easier to maintain when IDs or class names are stable
- ❌ Limited ability to traverse up the DOM tree
XPath
- ✅ More powerful for traversing complex DOM structures (e.g., going from child to parent)
- ✅ Useful for deeply nested or dynamically generated elements
- ❌ Can be slower and more brittle, especially with long or absolute paths

In most cases, prefer CSS selectors for simplicity and speed. Use XPath only when CSS selectors can’t locate an element effectively. Remember—stable locators = stable tests.

❌ Relying on Thread.sleep() – Use explicit waits instead
❌ Using brittle locators – Prefer unique IDs or CSS selectors over XPath when possible
❌ Hardcoding values – Abstract credentials and test data early

Avoiding these issues early will save you a lot of future refactoring.

Advanced Selenium Techniques

Once you’re comfortable with the basics, Selenium has the flexibility to support more advanced test structures and robust execution models—even if you’re not fully tied into a CI/CD pipeline.

1. Implementing the Page Object Model (POM)

Rather than repeating locators in every test, structure your automation with the Page Object Model. Each page of your app becomes a class or module, containing all locators and methods related to that page. This reduces duplication, improves maintainability, and helps scale your tests as your app grows.

2. Explicit Waits and Fluent Waits

Move beyond basic delays by mastering Selenium’s wait mechanisms. Explicit waits help handle dynamic elements, while fluent waits allow for polling and flexible timeout handling. This dramatically reduces flaky test behavior caused by slow-loading UI components.

3. Data-Driven Testing

Parameterize your tests with multiple data sets using tools like TestNG (Java), pytest (Python), or Mocha with data providers (JavaScript). This is essential for validating multiple conditions and edge cases in a single test structure.

4. Running Tests in Parallel

Use libraries like TestNG, Pytest-xdist, or WebDriverIO’s parallel execution feature to speed up your suite. Even without CI/CD, this can be helpful when validating across browsers or data sets locally.

5. Scaling with Selenium Grid or Cloud Providers

When you’re ready, Selenium Grid allows for distributed execution across machines. Alternatively, cloud services like BrowserStack or Sauce Labs provide cross-browser and cross-platform support with no infrastructure management required.

These techniques turn Selenium from a local test runner into a scalable automation engine—and mastering them ensures you’re ready to explore modern frameworks like Cypress next.

TDD, BDD, and Framework Choices in Selenium

While Selenium gives you raw control over browser automation, how you structure your tests matters just as much. This is where TDD (Test-Driven Development) and BDD (Behavior-Driven Development) come into play.

TDD with Selenium

In a TDD approach, you write your tests first, then write the minimum code needed to make them pass. While TDD isn’t limited to unit tests, applying it with Selenium means:

Writing failing Selenium tests for new UI behavior
Using tools like Mocha (JavaScript) or JUnit/TestNG (Java) to structure test-first development
Integrating automation into your sprint deliverables from day one

TDD works best when paired with reliable locators and a well-structured POM setup.

BDD with Selenium

BDD adds a layer of clarity by describing behaviors in plain language using Gherkin syntax (Given, When, Then). Tools like Cucumber (Java) or Cucumber.js let you:

Define user behaviors in .feature files
Map those behaviors to Selenium test steps (step definitions)
Improve collaboration between testers, devs, and non-technical stakeholders

BDD is ideal when cross-team understanding is important, especially in Agile environments.

Mocha and Chai in Selenium (JavaScript)

If you’re using JavaScript with Selenium, combining Mocha as the test runner with Chai for assertions provides a clean, readable structure:

Mocha handles test lifecycle and grouping (describe, it, beforeEach)
Chai gives expressive assertions (expect, should, or assert syntax)

This combo is especially valuable when writing modular, maintainable tests in JS.

A Word on Selenium IDE and BDD

One downside of starting with Selenium IDE is that it doesn’t support Gherkin or structured test syntax. It’s great for quick exploratory automation or recording flows, but:

It lacks semantic test structure
Doesn’t promote collaboration-friendly test descriptions
Can become chaotic for larger test suites

Use Selenium IDE as a learning tool or for spike testing—but migrate to real scripting with POM and Mocha/Cucumber if you want scalable, maintainable test automation.

What Comes Next?

Once you’re comfortable:

Implement the Page Object Model (POM)
Modularize test utilities and environment configs
Learn about running tests in parallel or in the cloud
Eventually explore integration with CI/CD when your team is ready

But until then, mastering Selenium in its raw form gives you a strong foundation in automation logic—the kind that translates to any tool or platform.

Conclusion: Start Small, Think Big

Selenium is still one of the best ways for QA testers to get started with browser automation. You don’t need a full tech stack or DevOps setup to begin—just a browser, a simple script, and a willingness to explore.

Start with Selenium IDE if you’re coming from manual testing, or write basic WebDriver scripts if you’re code-friendly. Either way, you’re building skills that scale—just like we discussed in Mastering the Core QA Skills, where foundational testing knowledge bridges manual and automation practices, even if your team isn’t fully automated yet.

Test smarter. Automate what matters. And don’t wait for the perfect setup—just get started.

🔗 Explore More:
Practice live at playground.qajourney.net
Get the full test code on GitHub: qajourney-automation-lab

0 Shares

Automation Testing with Selenium: A Practical Guide for QA Testers (No CI/CD Required)