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.

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. 

Traceability in software testing is the ability to connect and follow relationships between requirements, risks, test cases, defects, and code changes across the software lifecycle. It helps teams reason systematically about failures, gaps, and change, while providing visibility into what has been tested, what may be affected, and where uncertainty still exists. Traceability operates in multiple directions. Forward traceability follows requirements through implementation and testing to ensure expected behaviours are covered. Backward traceability links defects or test failures back to their originating requirements or risks. Horizontal traceability connects related artefacts at the same level, such as overlapping coverage across features, workflows, or services. Effective traceability requires all three perspectives, not just the vertical mapping many teams default to. A traceability link confirms that a test exists for a requirement not that the test is meaningful, well-designed, or passing. Traceability provides visibility into coverage relationships, but it does not guarantee coverage quality. The two should not be conflated. Connecting tests to explicit risks supports prioritisation, regression selection, release exposure assessment, and failure triage. Without risk linkage, traceability can incorrectly imply that all requirements carry equal importance, which rarely reflects the reality of systems under pressure. Traceability also strengthens impact analysis. When requirements change or defects are discovered, traceability links help teams identify which tests need review, which areas carry regression risk, and where coverage gaps may have been introduced. This becomes particularly valuable in large or distributed systems where the consequences of a change are not immediately obvious. Used well, traceability is a decision-making tool that helps teams test smarter, communicate coverage clearly, and respond to change with confidence rather than guesswork.

Load testing is a type of performance testing that evaluates how a system behaves under a defined workload, typically modelled on expected or peak production usage. Its primary goal is to determine whether the system can respond reliably, consistently, and within pre-defined performance thresholds when multiple users interact with it concurrently. Those thresholds expressed as Service Level Objectives or explicit acceptance criteria, must be agreed before the test runs. Without them, a load test produces observations, not pass or fail signals. Unlike stress testing, which pushes a system beyond its limits to identify breaking points, load testing operates within anticipated demand boundaries. It answers a focused question: does the system perform acceptably under the conditions it is expected to handle? A load test is only as meaningful as its workload model. This includes not just concurrent users or requests per second, but also the shape of the load: whether traffic ramps gradually, remains steady, or follows realistic production patterns such as a diurnal curve. Representative user journeys, think times, and session durations all matter. Wherever possible, the workload model should be derived from production traffic data or analytics rather than assumptions, this is one of the most consequential decisions in the entire exercise. Load testing measures response time, throughput, error rate, and resource utilisation across application, database, and infrastructure layers. It helps identify bottlenecks, slow dependencies, memory pressure, and scalability limitations. However, load tests reveal symptoms, not root causes. Diagnosing failures requires supporting telemetry metrics, distributed traces, logs, and profiling data collected during execution. The reliability of results also depends heavily on environment fidelity. If the test environment differs significantly from production in topology, configuration, data volume, or external dependencies, the conclusions may be misleading regardless of how well the test itself was designed. Effective load testing examines how performance degrades as demand increases, how the system recovers when load subsides, and whether user experience remains within acceptable bounds throughout. These behaviours matter as much as whether the system survives the load itself. Where tests involve sustained load over extended periods to observe memory growth or gradual degradation, this moves into the adjacent practice of soak testing, which carries its own distinct objectives. Load testing sits at the intersection of development, operations, and architecture. In organisations where ownership is unclear, it tends to be performed poorly or not at all. Treating it as a shared responsibilityoften under a performance engineering or site reliability function,, significantly improves both the quality of the tests and the organisational response to findings. In mature engineering organisations, load testing is not a one-time pre-release activity. It becomes part of continuous delivery pipelines and ongoing system health monitoring as systems change and user behaviour shifts.

cURL is a command-line tool for sending HTTP requests and inspecting raw responses. Testers use it to interact directly with API endpoints, bypassing UI and client-side layers that can obscure where a problem originates. It supports common HTTP methods (GET, POST, PUT, DELETE, PATCH), custom headers, request payloads, authentication schemes (Basic Auth, Bearer tokens, API keys), and TLS options, including testing against self-signed certificates using --insecure in non-production environments. From a testing perspective, cURL is valuable for reproducing issues with precision, validating API contracts, and testing authentication and authorisation flows in isolation. It also allows testers to assert specific response codes, headers, and payloads without additional tooling. Because it is scriptable, cURL can be embedded in shell scripts, CI pipelines, and lightweight smoke test suites, making it useful across both exploratory and automated testing. Unlike GUI-based tools such as Postman, cURL’s strength lies in its portability. It is available on most platforms, requires little or no setup, and produces commands that can be shared, reproduced in any terminal, and version-controlled alongside test assets.