Self-healing in software testing refers to the ability of automated test scripts or systems to adapt themselves when an application changes, without requiring human maintenance. Applications often evolve with new element IDs, altered layouts, or modified workflows, which can easily break test automation. A self-healing system detects these changes and automatically finds the best alternative way to continue the test.For example, if a test script is looking for a button with a specific locator and that locator changes after a new release, a self-healing mechanism can identify the button by using backup locators, attributes, or AI-driven pattern recognition, so the test does not fail unnecessarily.This approach reduces test maintenance effort, minimizes flaky failures, and keeps the feedback loop smooth even when the application is undergoing frequent changes. By making tests more resilient, self-healing helps teams focus on real defects rather than fixing broken scripts.

Cohesion is about how closely related the responsibilities of a module, class, or function are. A cohesive unit does one job and does it well. High cohesion means that everything inside that unit contributes directly to a single, well-defined purpose. Low cohesion means the unit is doing too many unrelated things, which often makes it harder to understand, test, and maintain.For example, a class that only handles user authentication is cohesive, whereas a class that mixes authentication, report generation, and email notifications is not. High cohesion helps improve clarity, reduces duplication, and ensures that changes are easier to manage.When systems have high cohesion and low coupling together, they become much easier to test because each part has a clear focus and fewer dependencies on other parts.

Coupling describes how much one module or component depends on another. Low coupling means that modules can work independently with minimal knowledge of each other. High coupling creates tight links where changes in one part can easily break another. For example, if a payment service directly relies on the internal structure of the order system, even small changes in that structure could cause failures.Reducing coupling helps in creating flexible and reliable systems. It allows testers to isolate and verify individual modules without needing the entire system to be in place, which makes testing more efficient.

Dead code refers to parts of a codebase that exist but are never executed or have no effect on the program’s outcome. This includes unused functions, unreachable conditions, or variables that are never referenced. While dead code does not alter how an application runs, it adds unnecessary weight, creates confusion, and makes both development and testing harder to maintain.From a testing perspective, dead code often appears in coverage reports as lines that are never executed. Identifying it can be done through practices such as static analysis, where automated checks highlight unreachable or unused code, or through code coverage, where unexecuted paths stand out during test runs. Development environments may also issue warnings about unused variables or unreachable logic. In addition, runtime monitoring and peer reviews are effective ways to confirm whether suspicious blocks of code are ever exercised.Removing dead code improves clarity, reduces the effort of writing and maintaining tests, and ensures test results focus only on the active and meaningful parts of the system.

A Heisenbug is a type of software bug that seems to change its behaviour or even disappear when we try to investigate it. The name comes from the Heisenberg Uncertainty Principle in physics, which suggests that the act of observing something can affect the thing being observed. In practice, a Heisenbug might show up during normal execution but vanish as soon as you run the debugger, add logging, or try to reproduce it under controlled conditions. This can happen due to timing issues, memory corruption, uninitialized variables, or race conditions. For example, a program might crash randomly in production, but when you attach debugging tools, the additional processing changes the timing and the bug no longer appears. These bugs are some of the most frustrating to test because they are inconsistent and hard to pin down. Testing for Heisenbugs often involves running the software under varied conditions, using stress or load tests, and monitoring behaviour in real-world environments. Since direct observation sometimes hides the issue, testers rely on indirect signals such as logs, error reports, and monitoring tools to uncover them.

Over-testing happens when the same functionality or area of a system is tested far more than necessary without adding any new value. It usually occurs when tests are duplicated, when coverage overlaps too much, or when teams focus heavily on low-risk areas while neglecting higher-risk ones. This can slow down the testing process, increase execution time, and make maintenance of test suites harder. In automation, over-testing is often seen in having multiple scripts performing the same checks in slightly different ways. In manual testing, it can appear as repeatedly running scenarios that do not provide fresh insights. Avoiding over-testing is not about reducing quality but about making testing smarter. By aligning test efforts with risk, prioritising critical paths, and reviewing test suites regularly, teams can focus their energy where it truly matters and keep testing both efficient and meaningful.

Lazy loading is a technique used to improve performance by delaying the loading of certain resources until they are actually needed. Instead of downloading everything when the page first loads, the browser only loads what is required for the visible part of the page, and loads other content later when the user scrolls to it or triggers an action.For example, an e-commerce site might load product images only when they appear on the screen instead of loading hundreds of images at once. This reduces the initial load time, saves bandwidth, and makes the page feel faster for the user.Lazy loading is commonly used for images, videos, and large data sets in web applications. From a testing perspective, it is important to verify that lazy-loaded elements appear correctly and function as expected when triggered. This includes checking that they remain accessible to all users, including those using assistive technologies or with JavaScript disabled.Testers should also watch for issues such as broken triggers, timing problems, or cases where the content does not load due to network delays.