From Algorithms to Agents: How My Research in Clustering Shapes My Automation Logic

"Just click this, type that, check this."

If this is how you think about test automation, you're building a house of cards.

Most automation engineers focus on actions—what to click, what to type, what to assert. But treating automation as just a sequence of actions leads to brittle scripts that shatter the moment the UI changes a single class name.

I don't look at automation as scripting. I look at it as a data problem.

Why? Because long before I was building automation frameworks in Python, my co-authors Hrishav Bakul Barua, Sauravjyoti Sarmah, and I were researching algorithmic efficiency in spatial databases. That research—published in 2012—didn't teach me a specific technique to copy-paste into Selenium. But it fundamentally shaped how I think about complex data problems.

The Foundation: The TDCT Algorithm

Back in 2012, Hrishav Bakul Barua, Sauravjyoti Sarmah, and I co-authored a research paper titled "A Density Based Clustering Technique For Large Spatial Data Using Polygon Approach" (TDCT).

The Problem We Solved

How do you find meaningful patterns (clusters) in massive, chaotic datasets—without getting overwhelmed by noise?

DBSCAN already supports arbitrarily shaped clusters and identifies noise. My research explored a polygon-based approach to density and spatial representation; it should not be read as introducing those capabilities to clustering.

• How the neighborhood definition changes the resulting density estimate.
• How spatial indexing and input distribution affect runtime.
• How to distinguish data-specific observations from general algorithmic claims.

Our Solution: Triangular Density

The paper examines a triangular polygon approach to spatial density. The useful connection to my automation work is how changing a representation changes the questions you can ask.

• Make the representation and assumptions explicit.
• Evaluate behavior on different shapes and densities.
• Inspect noise handling with a known dataset.

The Bridge: Why This Matters for Quality Engineering

"Dhiraj, what does spatial clustering have to do with Selenium?"

Not the code—the mindset.

It's About Problem Framing

When I encounter a complex automation challenge, I don't immediately think "what Selenium command do I need?" I think:

• What's the data structure here? (The DOM is a tree, test results are time-series data)
• What's the noise vs. the signal? (Which element attributes are stable? Which failures are true bugs?)
• How can I reduce complexity? (Can I optimize the problem's "geometry" like TDCT did?)

This mental model—trained by years of algorithmic research—influences every framework decision I make.

Applying the Mindset: Practical Examples

Example 1: Multi-Attribute Element Location with Fallback Logic

Brute-Force Approach (like naive spatial scanning—single point of failure):

# If ID changes, everything breaks
element = driver.find_element(By.ID, "checkout-btn-v3")

Algorithmic Approach (like TDCT's density-core identification—multiple data points):

from selenium.common.exceptions import NoSuchElementException, TimeoutException
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

def find_element_with_fallback(driver, strategies):
    # Use only reviewed locators that identify the same intended control.
    for locator in strategies:
        try:
            return WebDriverWait(driver, 2).until(
                EC.element_to_be_clickable(locator)
            )
        except TimeoutException:
            continue
    raise NoSuchElementException("No reviewed locator matched")

checkout_strategies = [
    (By.CSS_SELECTOR, "[data-testid='checkout']"),
    (By.CSS_SELECTOR, "button[aria-label='Checkout']"),
]
# Locate only; the test must still perform and verify the intended action.
checkout_button = find_element_with_fallback(driver, checkout_strategies)

This is an ordered fallback list, not statistical clustering or a measured confidence score. Every locator must identify the same intended control. Broad fallbacks can hide a regression by selecting the wrong element, so log the selected strategy and verify the action’s result.

Example 2: Self-Healing Element Location

Static Approach (brittle, noise-sensitive):

driver.find_element(By.ID, "submit-btn-v3")  # Breaks when ID changes

Adaptive Approach (cluster-like resilience):

# When an element isn't found, analyze multiple attributes:
# - Text content (stable?)
# - Class names (which are consistent?)
# - Position relative to stable anchors
# Then select the "highest confidence" match

This isn't literally running TDCT. But the thinking is the same: instead of relying on a single brittle identifier, we analyze multiple "data points" (attributes) to find the most stable combination.

The Tools I Build Reflect This Philosophy

When I created packages like Lumos ShadowDOM or Visual Guard, I wasn't consciously implementing clustering algorithms. But the design decisions reflect the same principles:

• Traversing Shadow DOM efficiently → Understanding the structure of the problem before brute-forcing
• Visual regression with SSIM → Using mathematical models (not pixel-by-pixel noise) to find meaningful differences
• Self-healing in my frameworks → Treating element attributes as "data points" with varying reliability

The research doesn't give me copy-paste solutions. It gives me a lens for seeing automation as a data problem, not a scripting problem.

Conclusion: Automation Isn't Just Code—It's Logic

Whether it's the TDCT algorithm my co-authors and I published years ago or the automation tools and libraries I build today, the goal remains the same:

The DOM is chaotic. Test data is chaotic. UI changes are chaotic.

But with the right algorithmic mindset—trained by research in one domain—we can bring that discipline to another domain entirely.

Read the Original Research

Read the original TDCT paper, by Hrishav Bakul Barua, Dhiraj Kumar Das, and Sauravjyoti Sarmah. IOSR Journal of Computer Engineering, volume 3, issue 6, September–October 2012, pages 1–9.