Two MoTacon attendees are on the left. The MoTaacon logo is in the center, and to the right a prompt to Get Your Ticket.

Ujjwal Kumar Singh

Ujjwal Kumar Singh profile image
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

🎂 MoTaBirthday | April 21, 2024
Open To
Speak
Write
Podcasting
Teach
Work
Ambassador
Call for Insights turns 45 image
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 ...
6 Jul
The Questions the Community Taught Me to Ask image
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...
2 Jul
8 days. 4 new experiences. 4 memorable moments. 4 firsts. image
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...
25 Jun
BTS.. before my first hosting session 🙂 image
 A few minutes before going live, checking notes, testing the mic, and hoping the internet would cooperate. 🙂
24 Jun
Untangling the DOM: How automation really breaks (and how to fix it) image
Browsers keep four different pictures of your page at once, and automation bugs live in the gap between them.
9 Jul
Prompt injections: A new opportunity for testers image
Generative AI apps and integrations are growing fast and so are the injection attacks. This time it's through harmless-looking plain text, aka prompts.
27 May
Being helpful, livestream gaming and the testing edge image
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.
20 Jul
The curse of the live demo… and other testing superstitions - Ep 123 image
Swap your team’s favourite quality superstitions, laugh at cursed demos and disappearing bugs, and turn “don’t deploy on Fridays” from folklore into smarter release habits.
13 Feb
Architectural smell 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) 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. StaleElementReferenceException 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) 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 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.
Subscribe to our newsletter