Ujjwal Kumar Singh
SDET @ Skeps
He/Him
Hi, I’m Ujjwal, a software tester and quality advocate. Exploring how quality works beyond tools and into systems, decisions, and trade-offs.
Substack: https://substack.com/@beinghumantester
Open To
Speak
Write
Podcasting
Teach
Work
Achievements
Certificates
Awarded for:
Achieving 5 or more Community Star badges
Activity
earned:
Being helpful, livestream gaming and the testing edge
earned:
Being helpful, livestream gaming and the testing edge
earned:
The Work Nobody Can See Doesn’t Count Toward Your Career
earned:
The Work Nobody Can See Doesn’t Count Toward Your Career
Contributions
A community-led episode on job hunting, scaling quality engineering, authentic career growth, AI adoption, gaming, and the value of staying connected when the industry feels noisy or uncertain.
Browsers keep four different pictures of your page at once, and automation bugs live in the gap between them.
On the 15th of January 2026 myself and Ujjwal Kumar Singh joined a call and pressed record. We were curious to see what would happen. A few weeks later I’d done the same with Neil Taylor and Clare ...
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.