An architectural smell is a commonly used architectural design decision or structural characteristic that suggests a potential problem in a software system. Like a code smell, it is not necessarily a defect, but it indicates that the architecture may become harder to maintain, evolve, or test over time. Architectural smells often arise from design trade-offs rather than programming mistakes and should be investigated in their context rather than assumed to be inherently wrong.  For software testers, architectural smells often surface as recurring automation challenges rather than isolated test failures. Examples include automation that repeatedly breaks because of unstable DOM references, poor testability, or tightly coupled components. Recognising an architectural smell helps shift the conversation from patching individual tests to improving the underlying design or choosing a more appropriate testing strategy.

Cumulative Layout Shift (CLS) is a Core Web Vitals metric that measures a page's visual stability by quantifying how much visible content unexpectedly moves during the page's lifecycle. A high CLS score indicates that elements shift position after they are displayed, often because images, advertisements, fonts, or dynamically loaded content change the page layout unexpectedly. A low CLS score means the page remains visually stable as users read and interact with it.  For software testers, layout shifts affect both user experience and automation reliability. A test may identify an element and calculate its position, only for the element to move before the interaction occurs, causing clicks to miss their target or fail altogether. Understanding CLS helps testers distinguish failures caused by visual instability from those caused by incorrect locators or application logic.

A StaleElementReferenceException is an automation error that occurs when a test tries to interact with a DOM element that is no longer attached to the current page. This commonly happens when modern front-end frameworks such as React, Vue, or Angular re-render parts of the user interface, replacing existing DOM nodes with new ones. Although the element may appear unchanged to the user, the reference previously stored by the automation tool is no longer valid. For software testers, a StaleElementReferenceException is often a sign of an automation design issue rather than a timing problem. Caching element references across page updates makes tests vulnerable to re-renders. A more resilient approach is to use locator-based interactions that re-query the DOM before each action, ensuring the test always works with the current element instance.

Server-side rendering (SSR) is a technique where a web server generates the initial HTML for a page before sending it to the browser. This allows users to see content more quickly and can improve the performance, reliability, and speed with which search engines index a page. After the page loads, JavaScript typically hydrates the HTML to make it fully interactive. For software testers, server-side rendering introduces a distinction between content being visible and the application being ready for interaction. A page may appear complete while event listeners and client-side logic are still loading. Understanding SSR helps testers recognise hydration-related failures and avoid assuming that a visible element is immediately ready for automation.

Hydration is the process of making a server-rendered web page interactive. After the browser receives and displays the initial HTML, JavaScript runs to attach event listeners, restore application state, and connect the static markup to the client-side framework. Until hydration completes, elements may appear fully rendered but not yet respond to user interactions. For software testers, hydration explains why an element can exist in the DOM and be visible on screen, yet still fail to respond to clicks or other actions. Tests that interact with the page before hydration finishes may become flaky, even though the application is behaving as designed. Understanding hydration helps testers distinguish between structural readiness and true application readiness, allowing them to use more reliable waiting strategies.

The Render Tree is the browser's runtime representation of what can actually be displayed and interacted with on a web page. It is built by combining the DOM, which provides the page structure, with the CSSOM, which provides styling information. Unlike the DOM, the Render Tree excludes elements that are not rendered, such as those with display: none, and includes only the information needed to paint the page and determine its layout. For software testers, the Render Tree helps explain why an element may exist in the DOM but still be impossible to click or see. Factors such as visibility, layout, overlapping elements, and pointer-events affect whether an element can receive user interactions. Many automation failures that appear to be locator problems are actually caused by differences between the DOM and the Render Tree. Understanding the Render Tree helps testers diagnose issues related to visibility, clickability, layout shifts, and interaction.

When I look at this iceberg, I see my own journey as a tester.  For a long time, I spent most of my attention on what was visible above the surface. Test cases, coverage percentages, pass rate...

The CSSOM (Cascading Style Sheets Object Model) is the browser's runtime representation of all the CSS applied to a page. It contains the styling rules that determine how elements should appear, including properties such as colour, size, visibility, layout, and positioning. The browser combines the CSSOM with the DOM to build the Render Tree, which is used to paint the page on screen.For software testers, the CSSOM explains why an element can exist in the DOM but still be invisible or impossible to interact with. Properties such as display: none, visibility: hidden, opacity: 0, or pointer-events: none affect how elements behave without changing the DOM structure. Understanding the CSSOM helps diagnose automation failures where an element is present but not visible or clickable.

Shadow DOM is a web standard that allows a component to have its own isolated DOM tree, separate from the main document. It is one of the core technologies behind Web Components and is designed to encapsulate a component's internal structure, styles, and behaviour. This isolation prevents CSS and JavaScript outside the component from accidentally affecting its internals, while also preventing the component's implementation details from leaking into the rest of the page. A Shadow DOM is attached to a host element through a shadow root, which can be either open or closed. An open shadow root can be accessed and inspected through JavaScript, while a closed shadow root hides its internal DOM from external scripts, making direct inspection and traversal impossible through standard browser APIs. For software testers, Shadow DOM affects how automated tests locate and interact with elements. Standard locator strategies, such as CSS selectors or XPath, cannot directly access elements inside a closed shadow root. This means automation failures may be caused by component encapsulation rather than incorrect locators or timing issues. In many cases, improving testability involves architectural decisions, such as exposing open shadow roots in test environments, providing dedicated test APIs, or testing behaviour at a higher integration level instead of attempting to bypass encapsulation.

The Document Object Model (DOM) is a programming interface for web documents. When a web browser parses an HTML document, it creates a tree-like hierarchy of objects called nodes. This live representation of the document enables programming languages such as JavaScript to dynamically read, modify, and update the page's content, structure, and attributes. Why it matters in software testing: Understanding the DOM is foundational for modern web testing, particularly in these areas:  Test Automation: UI automation frameworks (like Playwright, Cypress, and Selenium) interact directly with the DOM. Testers use the DOM's structure to create locators (like CSS Selectors or XPath) to find buttons, text fields, and links to interact with during automated tests.  Debugging and Exploratory Testing: Testers frequently use the "Elements" tab in browser Developer Tools to inspect the DOM. This helps investigate UI bugs, check hidden element states, or verify that the correct data is being rendered.  Accessibility (a11y) Testing: The DOM contains the attributes (such as ARIA roles, alt text, and tab indexes) that Accessibility Tree relies on. Inspecting the DOM allows testers to verify these accessibility tags are present and correct.  Timing and Synchronization: Many automation flakiness issues occur because a script tries to interact with an element before it has been fully rendered or attached to the DOM. Recognizing how the DOM updates dynamically helps testers write more robust wait strategies.  Modern web applications frequently update the DOM dynamically in response to user actions or API responses without reloading the page. Testers need to understand these changes to create stable locators and reliable synchronization strategies. 

A moment of speaking for the first time at OSSA moment of hosting the first MOT MasterclassA moment of uploading my first YouTube videoA moment of speaking at my first online webinar with the Conti...