Similar to software composition analysis, Static Application Security Testing (SAST) tools scan source code before it runs and without executing it (“white-box testing”).SAST scanners search for “dangerous” patterns, that match security flaws, for example SQL injections, Cross-Site Scripting (XSS) and hardcoded API keys/credentials. SAST tools are most effective when they are used, and their output applied before code is merged.

Behavior where the same input always produces the same output under the same conditions. Traditional automation frameworks behave deterministically, making test execution predictable, repeatable, and easier to debug. So what? Deterministic behavior provides a reliable baseline for test automation. When failures occur, they are typically caused by changes in the application or test environment rather than variability in the automation itself. Example: A locator that consistently identifies the same button will always interact with that button until the UI changes.

Artificial Intelligence is the broad science of making computers mimic human decision-making and problem-solving. It is a nested family of technologies. At the outer edge, you have general AI. Inside that, you find machine learning, where systems learn from patterns in data. At the very centre, you have deep learning. It tries to mimic the human brain using neural networks. AI is a powerful tool, but it is not a replacement for human thinking, nor is it ever likely to be. It is brilliant at finding patterns in mountains of data, giving simple answers to complex questions (context depending, of course), but it lacks common sense and empathy. Our job is to bridge that gap, ensuring that AI is safe and reliable. 

Panic Driven Development (PDD)The abandonment of good development practices by a company or individual in order to react to a perceived external threat or future risk. Example: "We started a PDD cycle because other companies are using AI to get ahead of us."

Default thinking is the natural, preferred approach for a tester when they look at a problem. It is the familiar path the mind takes based on its knowledge and experience. Everyone has their own starting point that feels comfortable. Whatever it is, it is just the first step of thinking. Default thinking is not wrong. It is a habit, shaped by experience, that develops over time. The important part is recognising that this first step is only the beginning of thinking. Testing becomes deeper when you think from different perspectives. Once you pass your starting point, you can choose to explore in other ways. There are many mindsets to learn, and you can strengthen your thinking with practice. The aim is not to remove the natural tendency. It is to expand it. When you understand your default, you can use it as a starting point rather than a place to stay. This gives you the freedom to choose the mindsets that best fit the problem.

Imagine driving with a GPS that updates every second versus one that recalculates every ten minutes. Both eventually get you to your destination, but one helps you correct mistakes almost immediately. Feedback density is how frequently your team receives useful information that helps it make better decisions.This is what feedback density is. It is the amount of useful learning a team generates over a given period of time. A team with high feedback density learns continuously through questions, reviews, testing, monitoring, and collaboration. A team with low feedback density spends the same amount of time working but learns much later, making mistakes more expensive to fix.Hanisha Arora

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.