QA/SDET Engineer

Software Testing is the process of evaluating and verifying that a software product or application does what it is supposed to do. It is important because it identifies defects, ensures reliability, reduces maintenance costs, and prevents catastrophic failures in production, ultimately ensuring the quality of the product for the end user.

1. QA (Quality Assurance): Process-oriented. It focuses on preventing defects by improving the processes used to create the software. 2. QC (Quality Control): Product-oriented. It focuses on identifying defects in the actual product before release. 3. Testing: The actual execution of software to find bugs and verify functionality. Testing is a subset of QC, and QC is a subset of QA.

QA is proactive and focuses on the 'how'—ensuring that the development processes are followed to minimize errors (e.g., audits, process definition). QC is reactive and focuses on the 'what'—examining the final product to ensure it meets requirements (e.g., peer reviews, software testing).

The primary objectives are: 1. Finding defects. 2. Gaining confidence in the quality level. 3. Preventing defects. 4. Ensuring the end product meets business and user requirements. 5. Providing information to stakeholders for decision-making.

STLC is a sequence of specific activities conducted during the testing process to ensure software quality goals are met. It is not just about execution; it involves a systematic approach from requirement analysis to test closure.

1. Requirement Analysis: Understanding what to test. 2. Test Planning: Defining strategy, scope, and resources. 3. Test Case Development: Writing detailed test steps and data. 4. Environment Setup: Preparing hardware/software for execution. 5. Test Execution: Running tests and logging bugs. 6. Test Closure: Analyzing results and preparing the summary report.

SDLC (Software Development Life Cycle) focuses on the entire lifecycle of software creation (Requirement -> Design -> Dev -> Test -> Deploy). STLC is a part of SDLC that focuses specifically on the testing phases and quality control activities.

A Test Plan is a formal document that describes the testing scope, strategy, objectives, resources, schedule, and deliverables. It contains items like: Test Items, Features to be tested, Pass/Fail criteria, Risks/Contingencies, and Environment requirements.

A Test Strategy is a high-level, static document (usually at the organizational or project level) that defines the testing approach. It outlines the testing levels, tools, and standards to be followed across the project.

A Test Plan is specific to a project/release and details 'what', 'when', and 'who'. A Test Strategy is a long-term guideline that defines the 'how' (the general approach) and is usually not changed frequently.

A Test Case is a set of conditions or variables under which a tester determines whether a system satisfies requirements. It includes Test ID, Description, Pre-conditions, Steps, Test Data, Expected Result, and Actual Result.

A good test case is atomic, reusable, and clear. Components include: 1. Unique ID. 2. Title/Description. 3. Pre-conditions. 4. Clear Test Steps. 5. Test Data. 6. Expected Result. 7. Priority/Severity. 8. Traceability to requirements.

A Test Scenario is a high-level statement of 'what to test' (e.g., Verify Login functionality). A Test Case is a detailed set of steps of 'how to test' (e.g., Step 1: Enter Username, Step 2: Enter Password...). One scenario can have multiple test cases.

Test Data is the input provided to the software during test execution to exercise specific features. It can be valid (for positive testing) or invalid (for negative testing), and can be hardcoded or pulled from files/DBs.

A Test Suite is a collection of test cases that are intended to be used to test a software program to show that it has some specified set of behaviors. Often grouped by module or testing type (e.g., Regression Suite, Smoke Suite).

Test Coverage is a metric used in software testing that measures the amount of testing performed by a set of tests. It can refer to requirement coverage (testing all business needs) or code coverage (testing all lines of code).

1. Requirement Coverage: Mapping tests to functional needs. 2. Code Coverage: (Unit testing) Statement, Branch, and Path coverage. 3. Risk Coverage: Testing high-risk areas first. 4. Browser/OS Coverage: Testing across different environments.

RTM is a document that maps and traces user requirements with test cases. It ensures that all requirements are covered by at least one test case and helps in impact analysis if a requirement changes.

A bug or defect is a mismatch between the expected result and the actual result of a software application. It is an error in the software that causes it to behave in an unintended or incorrect manner.

It is the specific states a bug goes through from discovery to closure.

1. New: Found for the first time. 2. Assigned: Given to a developer. 3. Open: Developer is analyzing it. 4. Fixed: Developer corrected it. 5. Retest: QA is checking the fix. 6. Verified/Closed: QA confirms it's gone. 7. Deferred/Rejected: Won't be fixed now or not a bug.

1. Error: A human mistake in the code. 2. Bug: Found by a tester before release. 3. Defect: Found in production by the end user. 4. Failure: When the system as a whole stops performing its function due to a bug.

Severity is the technical impact of the bug on the system (e.g., crash is High). Priority is the business urgency to fix it (e.g., typo on home page might be High Priority if it's the company name).

A crash that occurs only in an extremely obscure, rarely used legacy feature that no users interact with anymore. Technically severe (system fails), but not a priority to fix immediately.

A typo in the company's logo on the landing page or an incorrect brand color. It doesn't affect functionality (low severity), but it harms brand image significantly (high priority).

A blocker bug is a defect of the highest severity that prevents any further testing or use of the system. For example, a login page that crashes immediately, preventing access to the rest of the app.

Regression occurs when a change in one part of the code (new feature or bug fix) unintentionally breaks existing, previously working functionality.

Retesting is specifically testing a failed test case again to see if the bug is fixed. Regression Testing is testing the rest of the application to ensure the fix didn't break anything else.

Smoke Testing is a wide but shallow test of the entire system to ensure basic stability. Sanity Testing is a narrow but deep test performed on a specific component after a change to ensure it still makes sense.

Smoke is performed on a new build; if it fails, the build is rejected. Sanity is performed on a stable build with minor changes; it verifies the fix/change logic. Smoke = 'Wide', Sanity = 'Deep'.

A software testing method where the internal structure/design/implementation of the item being tested is not known to the tester. The tester focuses solely on inputs and outputs based on requirements.

A testing method where the internal logic, code structure, and implementation are visible to the tester. It involves testing the actual code, loops, and branches.

A combination of Black and White Box testing. The tester has partial knowledge of the internal data structures and algorithms, often used in API and Database testing.

Testing of individual components or units of code, usually performed by developers using frameworks like JUnit, TestNG, or NUnit.

Testing where individual units are combined and tested as a group to expose faults in the interaction between integrated units.

Testing conducted on a complete, integrated system to evaluate the system's compliance with its specified requirements. It's an end-to-end testing of the whole product.

User Acceptance Testing is the final phase where the end-users test the system to ensure it handles real-world scenarios and is ready for production.

System Testing is performed by the QA team to find bugs against technical specs. UAT is performed by the client/business users to ensure it meets business needs and is 'fit for use'.

A type of black-box testing that verifies that each function of the software application operates in conformance with the requirement specification.

Testing of 'how' the system behaves, rather than 'what' it does. This includes performance, load, stress, security, usability, and reliability.

Performance testing is a non-functional testing technique used to determine how a system performs in terms of responsiveness and stability under a particular workload. It focuses on speed, scalability, and reliability.

Load testing is the process of putting demand on a system and measuring its response. It determines how the application behaves when multiple users access it simultaneously, usually up to its expected maximum limit.

Stress testing involves testing the application beyond its normal operational capacity, often to a breaking point, to observe how the system fails and how it recovers (error handling and robustness).

Volume testing (or Flood testing) refers to testing the software application with a huge amount of data in the database to check the system's behavior and response time.

Spike testing is a subset of stress testing that evaluates how a system handles a sudden, extreme increase or decrease in user load.

Endurance testing checks if the system can sustain a continuous expected load for a long period (e.g., 12–24 hours) to identify memory leaks or performance degradation over time.

Load Testing verifies if the system can handle the *expected* peak load. Stress Testing verifies how the system behaves *beyond* the expected load to find the breaking point.

Security testing is the process of identifying vulnerabilities, threats, and risks in a software application and preventing malicious attacks from intruders. It ensures data confidentiality and integrity.

Also known as 'Pen Testing' or 'Ethical Hacking,' it is an authorized simulated cyberattack on a computer system, performed to evaluate the security of the system.

Vulnerability testing is the process of scanning and identifying security weaknesses (vulnerabilities) in the environment without actually exploiting them to cause damage.

Usability testing measures how easy and user-friendly the application is for an end user. It focuses on the user's ease of using the application, flexibility in handling controls, and the ability to meet objectives.

A type of non-functional testing to ensure the software runs on different hardware, operating systems, applications, network environments, or mobile devices.

The process of verifying that your web application works as expected across different browsers (Chrome, Firefox, Safari, Edge) and versions to ensure consistent UI and functionality.

Testing the application on different Operating Systems (Windows, macOS, Linux, Android, iOS) to ensure that the platform-specific behaviors do not break the app.

Database testing involves verifying the integrity of data, checking the schema, tables, triggers, and stored procedures. It ensures that data is stored and retrieved correctly without corruption.

API testing focuses on verifying the business logic of the application by testing the communication between different systems via requests (GET, POST, etc.) and responses, without the UI layer.

User Interface (UI) testing is the process of testing the visual elements of the application, such as buttons, fonts, colors, and layout, to ensure they match the design specifications.

E2E testing verifies the entire software product's flow from start to finish (e.g., from login to checkout) to ensure all integrated components work together correctly in a real-world scenario.

Exploratory testing is an unscripted testing approach where testers explore the app to find bugs that are not covered by documented test cases. It relies on the tester's experience and intuition.

Ad-hoc testing is performed without any formal documentation or plan. It is a 'break the system' approach where the tester randomly interacts with the app without following specific steps.

A technique where the tester provides random inputs to the system (like a monkey hitting keys) to see if the system crashes. It is used to test for unexpected behavior and robustness.

Testing one specific module or functionality thoroughly and repeatedly to ensure that the logic is solid and that the module is bug-free before moving to the next.

Alpha Testing is done in-house by the QA team or developers. Beta Testing is done by real users in their own environment before the final release to get real-world feedback.

Testing designed to ensure that the application is usable by people with disabilities (e.g., using screen readers for the visually impaired).

Internationalization (i18n) is making the code support multiple languages. Localization (l10n) is testing the app for a specific region (e.g., checking currency, date formats, and translated text for France).

A type of testing that determines how well the application is able to recover from crashes, hardware failures, or other catastrophic problems.

Verifying that the software installs and uninstalls correctly on different hardware and operating systems, and that all necessary files and shortcuts are created.

Testing specifically to ensure that the application can be updated from an older version to a newer version without losing data or breaking existing features.

Ensuring that the new version of the software is compatible with older hardware, older data formats, or older APIs used by clients.

A method of comparing two versions of a webpage or app against each other to determine which one performs better in terms of user engagement or conversion rates.

Standardized methods used to derive test cases from requirements or code to ensure maximum coverage with minimum effort. They are divided into Black Box and White Box techniques.

A technique where input data is divided into logical 'partitions' or groups. We assume that all values in a group will behave the same, so we only test one value from each group.

A technique based on the idea that bugs often hide at the boundaries of input ranges (e.g., if a field accepts 1-10, we test 0, 1, 2, 9, 10, 11).

Equivalence Partitioning tests a representative value *inside* a range. BVA specifically tests the *edges* and just outside the edges of that range.

A technique used to test complex business logic involving combinations of inputs. A table is created where each column represents a specific combination of inputs and their expected output.

Used when an application behaves differently depending on its current 'state' (e.g., an ATM where entering a PIN three times changes the state from 'Logged Out' to 'Blocked').

Derived from user requirements or 'Use Cases.' It focuses on the end-to-end interactions between the user (actor) and the system to achieve a specific goal.

An informal technique where the tester uses their experience to 'guess' where the developer might have made mistakes based on common past errors.

Simultaneous learning, test design, and execution. It emphasizes the freedom and responsibility of the individual tester to continually optimize the quality of their work.

A combinatorial technique that tests all possible pairs of input parameters, significantly reducing the number of test cases while maintaining high coverage for interaction bugs.

Positive Testing verifies the system works with valid data. Negative Testing verifies the system handles invalid data/scenarios gracefully without crashing.

A testing approach where the most critical features (highest probability of failure and highest business impact) are tested first and most thoroughly.

A white-box technique where 'mutations' (intentional small errors) are added to the source code to see if the existing test cases are strong enough to 'kill' the mutants.

An automated software testing technique that involves providing invalid, unexpected, or random data as inputs to a computer program to find security loops and crashes.

A white-box metric that ensures every possible branch (decision point like `if-else`) in the code is executed at least once during testing.

Ensures that every line of executable code in the source has been executed at least once during unit testing.

Ensures that every possible path (the specific sequence of statements) from the beginning of a function to its end is tested.

Focuses on testing the individual boolean sub-expressions within a complex decision statement (e.g., testing both `a` and `b` in `if (a && b)`).

A highly rigorous metric used in safety-critical systems. It ensures that each individual condition in a decision can independently affect the outcome of that decision.

1. Be descriptive yet concise. 2. Keep steps atomic. 3. Include clear expected results. 4. Ensure traceability. 5. Avoid dependencies between test cases where possible.

The use of software tools to execute tests and compare actual outcomes with predicted outcomes, allowing for repetitive tasks to be performed without manual intervention.

1. Faster execution (ROI). 2. Better coverage. 3. Reusability of scripts. 4. Reduced human error. 5. Ability to run tests 24/7 and in parallel.

1. High initial cost and effort. 2. High maintenance for unstable apps. 3. Cannot replace human intuition/exploratory testing. 4. Tool limitations (e.g., CAPTCHA).

Automate tests that are: 1. Repetitive (Regression). 2. High volume (Data-driven). 3. Critical paths. 4. Time-consuming to do manually.

Do not automate tests that are: 1. One-time only. 2. Frequently changing (UI unstable). 3. Subjective (UX/Usability). 4. Low risk/priority.

A strategy suggesting that unit tests should form the base (largest number), followed by API/Service tests, with UI tests at the top (smallest number).

Manual is human-driven, flexible, and better for UX/Ad-hoc. Automation is tool-driven, fast, and better for regression/repetitive tasks.

It depends on the project, but typically 70-80% is the target. 100% is unrealistic because some tests (UX, exploratory) require human eyes.

Return on Investment. It is calculated by comparing the cost of manual execution (over many cycles) vs the cost of developing and maintaining automation scripts.

A set of guidelines, protocols, and tools used for creating and designing test cases. It provides a structured approach to writing scripts and generating reports.

Common frameworks include: 1. Linear (Record & Playback). 2. Modular (Scripts based on modules). 3. Data-Driven (Separates data from logic). 4. Keyword-Driven (Uses keywords for actions). 5. Hybrid (Combination of various types). 6. BDD (Behavior-driven).

A framework where test input and output values are read from external data files (Excel, CSV, XML, JSON) instead of being hardcoded in the scripts. This allows the same script to be run with multiple sets of data.

In this framework, keywords (like 'click', 'login', 'verify') are associated with specific actions. Test cases are written as a series of these keywords in a table, allowing non-technical people to understand and create tests.

A Hybrid framework combines the best features of Data-Driven and Keyword-Driven frameworks. It uses external data for inputs and keywords for common actions, providing maximum flexibility and maintainability.

POM is a design pattern that creates an object repository for web elements. Each web page is represented by a class, and elements are defined as variables. This decouples the test logic from the UI structure.

1. Maintainability: If a UI change occurs, you only update the Page Class, not every test script. 2. Reusability: Page methods can be used across multiple test suites. 3. Readability: Test scripts look cleaner and more like user actions.

Page Factory is an extension to POM that uses the `@FindBy` annotation to initialize elements. It uses 'Lazy Loading,' meaning it only finds the element when it is actually interacted with in the code.

POM is a design pattern (concept). Page Factory is a built-in library in Selenium used to implement that pattern. Page Factory uses annotations and the `initElements` method.

BDD is an agile process that encourages collaboration between developers, QA, and business stakeholders. It uses natural language (Gherkin) to describe the behavior of an application.

TDD is a development technique where you write a failing test first, then write the minimum code to pass the test, and finally refactor. It ensures high code coverage and better design.

TDD is for developers to ensure code quality; it's technical. BDD is for the whole team to ensure requirements are met; it's behavior-focused.

Gherkin is a plain-text language used in BDD tools like Cucumber. It uses specific keywords to provide structure to requirements so they can be executed as automated tests.

1. Given: The pre-condition. 2. When: The action taken by the user. 3. Then: The expected outcome or result of that action.

The process of executing automated tests as part of the software delivery pipeline to obtain immediate feedback on the business risks associated with a software release candidate.

The practice of moving testing 'left' in the delivery pipeline (earlier in the SDLC). It involves QA collaborating during the design phase to find bugs when they are cheapest to fix.

Testing that happens 'right' in the pipeline—after deployment in production. This includes monitoring, A/B testing, and testing features in real-world environments.

The ongoing effort to update scripts as the application UI or business logic changes. High maintenance effort is often a sign of fragile locators or poor framework design.

1. Use stable locators (IDs/Names). 2. Implement robust waits (Explicit/Fluent). 3. Ensure clean test data. 4. Isolate tests from environment instability. 5. Quarantine flaky tests for analysis.

A good test is Independent (runs alone), Repeatable (consistent results), Self-validating (clear pass/fail), and Fast.

1. Do not automate 100%. 2. Use Page Object Model. 3. Externalize test data. 4. Run tests in CI/CD. 5. Keep tests small and focused (Atomic).

Selenium is a suite of tools for web automation. Components: 1. Selenium IDE (Record/Playback). 2. Selenium RC (Legacy). 3. Selenium WebDriver (Direct browser control). 4. Selenium Grid (Parallel execution).

A web automation framework that allows you to execute your tests against different browsers. It uses a browser's native support for automation to make direct calls to the browser.

IDE is a browser extension. RC used a JavaScript proxy (slow/legacy). WebDriver interacts directly with the browser's engine (fast/modern).

1. Open Source. 2. Supports multiple languages (Java, Python, C#, etc.). 3. Supports multiple browsers. 4. Large community support.

1. No support for desktop apps. 2. Cannot handle CAPTCHA or OTP. 3. No built-in reporting (needs TestNG/Extent). 4. Requires high technical skill.

Chrome, Firefox, Safari, Edge, Internet Explorer, and Opera.

Java, Python, C#, Ruby, JavaScript, and Kotlin.

It consists of: 1. Selenium Client Libraries. 2. JSON Wire Protocol / W3C Protocol. 3. Browser Drivers (chromedriver, etc.). 4. Real Browsers.

The test script sends HTTP requests (encoded in JSON) to the Browser Driver. The Driver communicates with the browser, executes the command, and returns the response back to the script.

`get()` waits for the whole page to load. `Maps().to()` is similar but also enables navigation history (back, forward, refresh).

`close()` closes the current focused window. `quit()` closes all windows/tabs and ends the WebDriver session completely.

Locators are the way to identify web elements (buttons, text fields) on a page. They are the 'address' of the element in the DOM.

ID, Name, ClassName, TagName, LinkText, PartialLinkText, XPath, and CSS Selector.

XPath (XML Path Language) is a syntax for finding elements on a web page by navigating through the structure of the HTML document.

Absolute starts from the root (`/html/...`); it's fragile. Relative starts with `//` and finds elements anywhere in the DOM; it's much more stable.

A way to find elements using CSS rules. It is often faster than XPath and has simpler syntax for classes and IDs.

XPath can navigate backwards (parent) and search by text. CSS is faster and better supported in older browsers, but cannot find parents or text.

Generally, CSS Selector is faster because it is highly optimized by browser engines. However, for modern browsers, the difference is often negligible.

An XPath that uses functions like `contains()`, `starts-with()`, or `text()` to find elements whose attributes (like ID) change every time the page loads.

1. Use dynamic locators (contains/siblings). 2. Use Explicit Waits. 3. Use indexing or unique parent attributes.

Standard methods to interact with the browser, such as `click()`, `sendKeys()`, `clear()`, `getText()`, and `getAttribute()`.

`findElement()` returns a single `WebElement` (or error). `findElements()` returns a `List<WebElement>` (or empty list if nothing found).

`getText()` returns the visible text inside the tags. `getAttribute()` returns the value of a specific attribute (e.g., 'value', 'href', 'title').

By using the Select class. You can select by Index, Value, or Visible Text.

A specialized class for interacting with `<select>` and `<option>` tags, providing easy methods for selection and de-selection.

Use `click()` to toggle them. Use `isSelected()` to check their current state.

By switching to the alert using `driver.switchTo().alert()`, then calling `accept()`, `dismiss()`, or `sendKeys()`.

Use `getWindowHandles()` to get all IDs, then `switchTo().window(id)` to move to the desired tab or window.

Use `driver.switchTo().frame()`. You can switch by Index, Name, or WebElement ID. Use `defaultContent()` to switch back to the main page.

A `<frame>` is for older HTML layouts; an `<iframe>` (inline frame) embeds a document into a part of a page. Selenium handles both the same way via `switchTo().frame()`.

I use `driver.getWindowHandles()` which returns a Set of unique window IDs. I then iterate through the set and use `driver.switchTo().window(handleId)` to move focus. To return to the original window, I store the parent handle using `driver.getWindowHandle()` at the start.

WebDriver wait is a mechanism used to handle synchronization issues. It pauses the execution of the script until certain conditions are met, preventing 'NoSuchElementException' or 'ElementNotInteractableException' due to slow loading pages.

1. Implicit Wait: A global timeout set once for the driver life; it tells WebDriver to poll the DOM for a set time before failing. 2. Explicit Wait: A specific wait for a specific element and a specific condition (e.g., `elementToBeClickable`). It is more efficient and recommended for AJAX-heavy apps.

FluentWait is a type of explicit wait that allows you to define the maximum time to wait for a condition, as well as the frequency (polling interval) with which to check the condition. You can also configure it to ignore specific exceptions like `NoSuchElementException`.

Explicit wait (`WebDriverWait`) is a specialized version of FluentWait with a default polling interval (usually 500ms). FluentWait is more customizable, allowing you to set your own polling frequency and ignore specific exceptions during the wait period.

Technically, never in production scripts. It is a 'Static Wait' that pauses the thread for the exact time regardless of whether the element is ready, making tests slow and brittle. It should only be used for quick local debugging.

I handle them primarily using Explicit Waits and Fluent Waits. I avoid implicit waits when using explicit ones to prevent unpredictable timeout conflicts. I ensure the `ExpectedConditions` match the user's intent, such as waiting for visibility or clickability.

It occurs when a reference to an element is no longer valid because the element has been deleted or the DOM has refreshed after the element was originally found. The element is 'stale' or 'dead' in the eyes of the driver.

1. Refresh/Re-find: Re-locating the element right before interaction. 2. Try-Catch: Catching the exception and attempting to find the element again. 3. ExpectedConditions: Using `refreshed(ExpectedConditions...)` which waits for the element to be re-attached.

It is thrown by `findElement()` when the locator provided cannot find any element in the DOM at the current moment. This is usually solved by adding proper waits.

Thrown when a command does not complete within the allotted time. It most commonly occurs when an Explicit Wait fails to find the expected condition within the specified time limit.

It occurs when an element is present in the DOM but is in a state that prevents interaction—for example, it is hidden by another element, is off-screen, or is disabled.

I cast the `WebDriver` instance to the `TakesScreenshot` interface and use the `getScreenshotAs(OutputType.FILE)` method. I then use `FileUtils` to copy the file to a permanent location.

If the input tag is `type='file'`, I simply use `sendKeys('full/path/to/file')` on the element. If it's a custom button that opens a Windows dialog, I use the Robot Class or AutoIT (though sendKeys is the cleaner, preferred way).

Selenium cannot interact with the 'Save As' browser dialog. I handle this by setting Browser Preferences (ChromeOptions) to define a default download directory and disable the download prompt, then I verify the file exists in that folder using Java code.

I use the Actions class. I create an instance of Actions, then use the `moveToElement(element).perform()` method to simulate the mouse moving over the element.

The Actions class is used to handle complex user interactions like mouse movements, drag and drop, double clicks, and keyboard combinations that cannot be performed by simple `WebElement` methods.

Using `actions.dragAndDrop(source, target).perform()`. Alternatively, I use a combination of `clickAndHold(source)`, `moveToElement(target)`, and `release().perform()`.

By using the `contextClick(element).perform()` method of the Actions class.

By using the `doubleClick(element).perform()` method of the Actions class.

Using the `sendKeys()` method for typing, and the `Actions` class methods like `keyDown(Keys.CONTROL)` and `keyUp(Keys.CONTROL)` for complex combinations like Ctrl+A or Ctrl+C.

Since WebDriver doesn't have a direct scroll command, I use JavaScriptExecutor. I execute `window.scrollBy(0, 500)` for pixel-based scrolling or `arguments[0].scrollIntoView(true)` to scroll to a specific element.

It is an interface that allows WebDriver to execute JavaScript directly within the browser context. It's used as a 'backup' for tasks WebDriver struggles with, like clicking hidden elements or scrolling.

1. When `click()` doesn't work due to overlapping elements. 2. To scroll. 3. To interact with elements in the Shadow DOM. 4. To change attribute values (like making a hidden element visible) for testing purposes.

I cast the `driver` to `JavascriptExecutor`, then call `executeScript('js_code_here', optional_arguments)`.

Headless testing is running your browser automation without a visible Graphical User Interface (GUI). The browser runs in the background. It is faster and commonly used in CI/CD environments where no monitor is available.

By using ChromeOptions or FirefoxOptions. I use `options.addArguments('--headless')` and pass these options to the WebDriver constructor.

Selenium Grid is a tool used for distributed test execution. It allows you to run tests on different machines (Nodes), different operating systems, and different browsers simultaneously from a central point (Hub).

The Hub is the central server that receives the test requests and distributes them to the available Nodes. Nodes are the machines where the actual browser instances are running and tests are being executed.

I set the remote address of the Hub in `RemoteWebDriver`, and use a testing framework like TestNG to trigger multiple threads. The Grid Hub automatically allocates the requests to free Nodes matching the `DesiredCapabilities`.

Selenium cannot solve CAPTCHA by design. To handle it: 1. Disable it in the test environment. 2. Use a 'backdoor' API to get the code. 3. Ask developers for a 'static' CAPTCHA value for testing.

Similar to CAPTCHA, I typically ask developers to provide a fixed OTP for test accounts or use a 3rd party service (like Twilio) to read the SMS via an API and then input it into the app.

Selenium's standard `findElement` cannot find elements inside a Shadow Root. I use `JavascriptExecutor` to get the shadow root first, then find the element within that root, or use Selenium 4's `getShadowRoot()` method.

The Robot class is a Java AWT class used to generate native system input events for test automation, such as mouse clicks and key presses outside the browser window (e.g., OS dialogs).

I use ChromeOptions. I add the argument `options.addArguments('--disable-notifications')` to prevent the browser from showing the 'Allow/Block' notification popups.

Using `options.setAcceptInsecureCerts(true)` in ChromeOptions. This tells the browser to bypass the 'Your connection is not private' warning page for self-signed or invalid certificates.

I use `driver.manage().getCookies()`, `addCookie(cookie)`, or `deleteAllCookies()`. This is useful for testing login persistence or clearing state between tests.

There isn't a direct method, so I use `driver.manage().deleteAllCookies()` and sometimes execute JavaScript to clear `localStorage` and `sessionStorage`.

I use a `HashMap` to define preferences (like download directory) and pass it to `ChromeOptions` using `options.setExperimentalOption('prefs', map)`.

It is a class used to set properties for browsers (like version, platform) to perform cross-browser testing. In Selenium 4, it is largely replaced by specific `Options` classes like `ChromeOptions`.

These are specialized classes used to customize the browser session, such as enabling headless mode, disabling extensions, or setting binary paths.

Browser-level auth popups (Basic Auth) can be bypassed by passing the credentials in the URL: `http://username:password@url.com`.

I iterate through the `<tr>` (rows) and `<td>` (cells) tags. I often use dynamic XPaths like `//table//tr[i]/td[j]` to locate specific data within the grid.

Selenium doesn't do this natively. I use the Apache POI library to open the workbook, access the sheet, and iterate through the rows and cells to fetch data.

It is an open-source Java library used to read, write, and create Microsoft Office files, most commonly used in automation for Data-Driven Testing with Excel.

By adding the TestNG dependency and using TestNG annotations like `@Test`, `@BeforeMethod`, and `@AfterMethod` to control the execution flow and generate reports.

Similarly to TestNG, by using JUnit annotations like `@Test`, `@Before`, and `@After`. JUnit is more common for pure unit testing but is widely used for smaller automation projects.

TestNG is more advanced for automation: it supports Dependency testing, Data Providers, Parallel execution via XML, and has more versatile annotations compared to JUnit.

They are keywords like `@Test`, `@BeforeClass`, `@AfterSuite` that define how the test methods should be executed and set up.

Suite -> Test -> Class -> Method. `@BeforeSuite` runs first, followed by `@BeforeTest`, `@BeforeClass`, and finally `@BeforeMethod` before each `@Test`.

1. @BeforeMethod: Runs before every individual `@Test` method in the current class. 2. @BeforeTest: Runs once before any test method belonging to the `<test>` tag in the `testng.xml` file starts.

It is a configuration file used in TestNG to define test suites, group test cases, pass parameters to methods, and manage parallel execution. It serves as the entry point for running a specific set of automation tests.

In the `testng.xml` file, I set the `parallel` attribute on the `<suite>` or `<test>` tag (e.g., `parallel='methods'` or `parallel='classes'`) and define the `thread-count`. This allows multiple tests to run simultaneously in different browser instances.

A DataProvider is a method that returns a 2D array of objects. It is used to pass multiple sets of data to a single `@Test` method, enabling Data-Driven Testing within the same script.

I separate test logic from test data. I use a DataProvider in TestNG to fetch data from an external source (like an Excel file using Apache POI or a JSON file) and inject it into the test parameters.

Parameterization allows me to pass values (like browser names or URLs) from the `testng.xml` file into the test methods using the `@Parameters` annotation. This makes scripts more flexible across environments.

I use the `dependsOnMethods` or `dependsOnGroups` attribute in the `@Test` annotation. If the 'dependency' test fails, TestNG will skip the dependent tests, saving execution time.

1. Hard Assertion: Throws an exception immediately and stops the test execution if the condition fails. 2. Soft Assertion: Continues the test execution even if an assertion fails, logging the failure to be reported at the end via `assertAll()`.

AssertJ is a Java library that provides a fluent and rich interface for writing assertions. It makes test code more readable with 'human-like' syntax, such as `assertThat(user.getName()).isEqualTo('John').isNotNull();`.

Since Selenium doesn't have built-in reporting, I integrate it with TestNG (standard HTML reports), Extent Reports (rich interactive dashboards), or Allure Reports (detailed lifecycle visualizations).

API Testing is a type of software testing that involves verifying Application Programming Interfaces directly. It bypasses the UI and focuses on the business logic, data integrity, and security of the communication between systems.

UI testing focuses on the look and feel and user experience. API testing focuses on the business layer, is much faster to execute, more stable (less prone to UI changes), and allows for earlier bug detection in the SDLC.

REST (Representational State Transfer) is an architectural style for designing networked applications. It uses standard HTTP methods, is stateless, and typically uses JSON or XML for data exchange.

SOAP (Simple Object Access Protocol) is a strict protocol for exchanging structured information. It relies on XML-based messaging and usually works over HTTP or SMTP, offering high security and transaction compliance.

REST is a lightweight architectural style supporting various formats (JSON, XML). SOAP is a strict protocol only supporting XML. REST is generally faster and easier to scale, while SOAP is more secure and used in financial/enterprise systems.

1. GET: Fetches data. 2. POST: Creates a new resource. 3. PUT: Updates/replaces an existing resource. 4. PATCH: Partially updates a resource. 5. DELETE: Removes a resource.

PUT replaces the entire resource with the new payload. PATCH only updates the specific fields provided in the request body, leaving other fields unchanged.

They are 3-digit numbers from the server indicating the result of a request: 2xx (Success), 3xx (Redirection), 4xx (Client Error), and 5xx (Server Error).

200 OK means the request was successful and data was returned. 201 Created means the request was successful and a new resource was successfully created on the server.

4xx errors are client-side (e.g., 404 Not Found, 400 Bad Request). 5xx errors are server-side (e.g., 500 Internal Server Error, 503 Service Unavailable).

401 Unauthorized means the user is not authenticated (login failed). 403 Forbidden means the user is authenticated but does not have permission to access that specific resource.

An endpoint is a specific URL where an API can access the resources it needs to perform its function (e.g., `https://api.example.com/v1/users`).

A Request is the data sent by the client (URL, headers, body). A Response is the data sent back by the server (status code, headers, body).

JSON (JavaScript Object Notation) is a lightweight, human-readable data-interchange format based on key-value pairs. It is the most common format used in modern REST APIs.

XML (Extensible Markup Language) is a markup language used to store and transport data. It uses tags to define objects and is more verbose than JSON.

JSON is less verbose, faster to parse, and uses arrays. XML is tag-based, supports schemas (XSD), and is generally more complex to process.

The process of verifying the identity of the client calling the API to ensure they are who they claim to be (e.g., via username/password or API keys).

The process of determining what an authenticated user is allowed to do (e.g., a 'Viewer' can only GET, while an 'Admin' can POST and DELETE).

Authentication is 'Who are you?'. Authorization is 'What are you allowed to do?'.

A type of authentication where the client sends a security token (like a JWT) in the `Authorization` header prefixed with 'Bearer '. The server trusts whoever 'bears' the token.

An industry-standard protocol for authorization that allows applications to gain limited access to user accounts on an HTTP service without sharing passwords.

A simple form of authentication where a unique identifier (key) is passed in the header or query string to identify the project or user calling the API.

A simple authentication scheme where the client sends a Base64-encoded string of `username:password` in the HTTP `Authorization` header.

Postman is a popular API platform for developers to design, build, test, and iterate their APIs. It provides a GUI for making requests and writing automated test scripts.

I use the 'Tests' tab in a request to write JavaScript snippets using the `pm.test()` and `pm.expect()` functions to validate status codes, response times, and body content.

Collections are groups of saved API requests. They help in organizing tests, running them in sequence, and sharing them with team members.

They are key-value pairs used to store values that change depending on the environment (e.g., `base_url` for Dev vs Prod). This allows the same collection to run against different servers.

Variables that are available across all collections and environments within a Postman workspace. Used for values that never change across the entire project.

By extracting a value from a response (e.g., an ID or Token) in the 'Tests' tab and saving it to an environment variable, then using that variable in the next request's URL or body.

Newman is a command-line collection runner for Postman. It allows you to run and test a Postman collection directly from the terminal, making it essential for CI/CD integration.

I use the command `newman run <collection_file_name> -e <environment_file_name>`. This executes the tests and displays a summary in the console.

REST Assured is a Java library that provides a domain-specific language (DSL) for writing powerful, maintainable tests for RESTful APIs.

I use the BDD-style syntax: `given()` (params/headers), `when()` (method/URL), and `then()` (assertions/validations).

1. Given: Configuration (base URI, path params, body, headers). 2. When: Action (GET, POST call). 3. Then: Validation (status code check, body assertion).

I use the `body()` method combined with Hamcrest matchers (e.g., `then().body('name', equalTo('John'))`) or by de-serializing the response into a POJO class.

Using `body()` and an XPath expression within REST Assured to target specific nodes in the XML structure and verify their values.

I use the `jsonPath()` method to query specific fields (e.g., `String id = response.jsonPath().get('id');`) for use in subsequent tests.

JSONPath is a query language for JSON, similar to how XPath is used for XML. It allows you to select and extract specific elements or nodes from a JSON document.

XPath is a syntax for defining parts of an XML document. It uses path expressions to navigate through elements and attributes in an XML file.

I use JSON Schema or XSD to verify that the structure, data types, and required fields of the API response match a predefined template, ensuring the contract hasn't changed.

Contract testing is a technique for testing an integration point by checking each application in isolation to ensure the messages it sends or receives conform to a shared understanding that is documented in a 'contract'. It ensures that a provider (API) doesn't break a consumer (Frontend/Mobile).

API mocking is the process of simulating the behavior of a real API. This is useful when the actual API is under development, unstable, or expensive to use. Tools like WireMock or Postman Mock Servers are used to return predefined responses.

WireMock is a tool for mocking HTTP-based APIs. It allows you to configure 'stubs' that match specific request patterns (URL, headers, body) and return a specific response, including status code and delays to simulate latency.

I use the `multiPart()` method in REST Assured or the 'form-data' body type in Postman. I pass the file control name along with the file object or path to verify the server receives and processes the file correctly.

I verify that passing query parameters like `page` and `size` (or `limit` and `offset`) returns the correct subset of data and that the response contains metadata like `total_pages` or `next_link`.

I use tools like JMeter or K6. I define a script that sends thousands of concurrent requests to the endpoint and monitor metrics like Response Time (latency), Throughput, and Error Rate.

It is a security and performance check to ensure the API correctly restricts the number of requests a single user/IP can make in a given timeframe. I test this by sending rapid requests until I receive a 429 Too Many Requests status code.

I check for: 1. Broken Object Level Authorization (BOLA). 2. Proper use of HTTPS. 3. Input validation to prevent injections. 4. Exposure of sensitive data in headers or error messages. 5. Validity of JWT signatures.

It is an attack where malicious SQL code is inserted into input fields (like query params or request body) to manipulate the backend database. I test this by inputting characters like `' OR 1=1 --` to see if the API leaks unauthorized data.

Unlike REST, GraphQL uses a single POST endpoint. I test by sending a JSON body containing a `query` or `mutation`. I verify that the response structure matches the requested fields and that the 'errors' array is empty for successful calls.

It is the process of verifying that an application designed for mobile devices works as expected. It covers functionality, usability, and performance across various OS (Android/iOS) and hardware configurations.

1. Mobile Web: Run in mobile browsers; focus on responsive design and cross-browser compatibility. 2. Native App: Installed directly on the OS; focus on OS-specific gestures, hardware sensors (GPS/Camera), and offline storage.

Appium is an open-source, cross-platform automation tool for native, hybrid, and mobile web apps. It follows a 'client-server' architecture and uses the WebDriver protocol, allowing you to use the same API for both Android and iOS.

It consists of: 1. Appium Client: Your test script. 2. Appium Server: A Node.js server that receives HTTP requests. 3. Drivers: Like UIAutomator2 (Android) or XCUITest (iOS) that execute commands on the device.

1. Node.js installed. 2. Appium Server. 3. Java JDK. 4. Android Studio (for Android SDK) or Xcode (for iOS). 5. Appium Inspector for element identification.

Selenium is for web browsers on desktops. Appium is for mobile apps (Native/Hybrid/Web) on real devices or emulators. Appium essentially extends the Selenium WebDriver protocol to include mobile-specific commands.

They are a set of key-value pairs (JSON object) sent by the client to the Appium server to define the session. Examples: `platformName`, `deviceName`, `app`, `automationName`, and `udid`.

1. `platformName`: Android or iOS. 2. `deviceName`: The model of the phone. 3. `app`: The absolute path to the .apk or .app file to be tested.

Android uses the UIAutomator2 driver and `.apk` files. iOS uses the XCUITest driver and `.app` or `.ipa` files. iOS automation requires a macOS machine with Xcode installed.

I use the Appium Inspector tool or uiautomatorviewer for Android. These tools allow me to see the UI hierarchy and find locators like `accessibilityId`, `xpath`, or `id`.

It is a testing framework by Google that provides a set of APIs to build UI tests. Appium uses it as a driver to interact with Android applications.

It is Apple's official UI testing framework. It allows developers and testers to write tests for iOS apps using Swift or Objective-C. Appium uses it for iOS automation.

A Native App is built entirely for one OS. A Hybrid App is a native wrapper around a web-view. In automation, I identify if the element is inside a 'Web Context' and switch to it if necessary.

A WebView is a component that displays web content (HTML/CSS) inside a native app. To automate it, I must switch the driver context from `NATIVE_APP` to `WEBVIEW_<name>`.

I use `driver.getContextHandles()` to find available contexts and `driver.context('context_name')` to switch. I use this when moving from a native menu to a web-based payment page.

ADB is a versatile command-line tool that lets you communicate with an Android device. It facilitates actions like installing apps, debugging, and providing access to a Unix shell.

1. `adb devices`: List connected devices. 2. `adb install <file>`: Install app. 3. `adb shell`: Open terminal on device. 4. `adb logcat`: View device logs. 5. `adb push/pull`: Transfer files.

To install: `adb install path/to/app.apk`. To uninstall: `adb uninstall <package_name>` (e.g., `com.example.app`).

I use `adb shell screencap -p /sdcard/screen.png`, then `adb pull /sdcard/screen.png` to bring the file to my computer.

An Emulator is software that mimics hardware. A Real Device is physical hardware. Real devices are critical for testing battery, network carrier signals, and high-performance graphics.

In Appium, I use the W3C Actions API or the `PointerInput` class to define sequences of touch movements, like pressing down, moving to coordinates, and lifting up.

It was the legacy class used for gestures (tap, press, longPress). It is now deprecated in newer versions of Appium in favor of the W3C Actions API.

I use a sequence of touch actions or a specialized script like `mobile: scroll` (Android) or `mobile: swipe` (iOS), providing directions like 'up', 'down', 'left', or 'right'.

I use `driver.switchTo().alert()` and then call `accept()` or `dismiss()`. For native OS permissions (like location), I often use desired capabilities like `autoGrantPermissions: true`.

I automate pulling down the notification drawer, finding the notification by its text or ID, and clicking it to verify it opens the correct deep-link or activity in the app.

I run the same automation scripts on a variety of emulators and real devices with different aspect ratios and resolutions to ensure elements don't overlap or become unreachable.

I use `driver.rotate(ScreenOrientation.LANDSCAPE)` or `PORTRAIT` in the script to verify that the UI adapts correctly without crashing or losing state.

Device farming is a service where you can remotely access and run tests on hundreds of real mobile devices hosted in a data center, rather than buying them all yourself.

They are cloud platforms that provide instant access to thousands of real mobile devices and browsers. They allow QA engineers to run Appium and Selenium tests in parallel at scale.

I update the Appium script's 'Remote URL' to point to the cloud provider's hub and include my credentials and desired capabilities in the script.

Performance testing evaluates the speed, responsiveness, and stability of a system. Types include Load, Stress, Endurance, Spike, and Scalability testing.

Performance is the umbrella term for testing system speed and stability. Load is a specific type that checks if the system can handle the *expected* peak volume of users.

Throughput is the amount of work completed by the system per unit of time (e.g., Requests per second or Transactions per minute). High throughput is usually a sign of a healthy system.

The total time taken from the moment a user sends a request until the system provides a response. It is the most critical metric for user experience.

Latency is the time it takes for a data packet to travel from the source to the destination (network delay). It is a subset of the total response time.

1. Concurrent Users: Real users accessing the app at the same time. 2. Virtual Users (VUs): Simulated users created by a performance tool (like JMeter) to mimic real users.

The time it takes to reach the full number of virtual users in a test. For example, if you want 100 users and a 50-second ramp-up, the tool adds 2 users every second.

The delay between a virtual user's actions (e.g., waiting 5 seconds after clicking 'Add to Cart' before clicking 'Checkout'). It makes load tests feel more realistic.

Pacing is the delay between consecutive iterations of a test script. It controls how many total transactions a virtual user performs per hour.

Apache JMeter is an open-source Java tool used for load testing and performance measurement of web applications, APIs, and databases.

JMeter is Java-based and uses a multi-threaded architecture. Each thread represents a 'Virtual User' that executes the test plan independently. It uses Samplers to send requests, Configuration Elements to manage data, and Listeners to aggregate results.

A Test Plan is the root element. It contains: 1. Thread Groups. 2. Samplers (HTTP, FTP). 3. Logic Controllers. 4. Listeners. 5. Configuration Elements (Cookies, Headers). 6. Assertions.

The Thread Group is the starting point of any test plan. It defines the number of virtual users, the ramp-up period, and the number of times to execute the test (loop count).

The most common sampler in JMeter. It tells JMeter to send an HTTP/HTTPS request to a specific server. You can configure the Path, Method, Parameters, and Body data.

Listeners are used to view and analyze the results of the performance test. Common examples include 'View Results Tree' (for debugging), 'Summary Report', and 'Aggregate Graph'.

Assertions are used to validate the response received from the server. For example, a 'Response Assertion' can check if the status code is 200 or if the response body contains a specific success message.

Timers are used to introduce 'Think Time' between requests to simulate realistic human behavior. Without timers, JMeter would send requests as fast as the network allows, which is unrealistic.

1. Constant Timer: Pauses the thread for a fixed, exact amount of time. 2. Gaussian Random Timer: Pauses for a random amount of time based on a normal distribution, making the load more varied and realistic.

I use the CSV Data Set Config element. This allows me to read values (like usernames and passwords) from a CSV file and use them in the requests using the `${variable_name}` syntax.

A configuration element used to read lines from a text file and split them into variables. It is essential for large-scale tests requiring unique data for every virtual user.

I use Post-Processors. For JSON, I use the 'JSON Extractor' with JSONPath. For HTML/XML, I use the 'Regular Expression Extractor' or 'XPath Extractor'.

Correlation is the process of extracting dynamic values (like Session IDs or Tokens) from a response and passing them into subsequent requests. This is mandatory for testing authenticated flows.

I use the 'HTTP(S) Test Script Recorder'. I set JMeter as a proxy in my browser, and as I navigate the app manually, JMeter captures every HTTP request and adds it to the Test Plan.

A component that allows JMeter to act as a proxy between the browser and the web server. It records all traffic into samplers, which serves as the base for building a performance script.

I add an HTTP Cookie Manager to the Test Plan. It automatically stores and sends cookies for each thread, just like a real browser handles sessions.

I use the command `jmeter -n -t [test_plan.jmx] -l [result_file.jtl] -e -o [report_folder]`. Running in Non-GUI mode is mandatory for actual load tests to save system resources.

By adding the `-e -o` flags in the command line execution. JMeter generates a dashboard with graphs for Response Times, Error Percentage, and Throughput.

It involves using one Controller machine to manage multiple Worker machines. The Controller sends the test plan to Workers, which then generate the actual load. This is used when a single machine's CPU/RAM can't handle the required number of virtual users.

Gatling is an open-source performance testing tool based on Scala and Akka. It uses an asynchronous, non-blocking engine, allowing it to handle more virtual users per machine compared to JMeter.

Locust is a Python-based performance testing tool. It allows you to write test scenarios in pure Python, making it very popular for developers and SDETs who prefer code over GUIs.

It is a type of backend testing that involves verifying the schema, tables, triggers, and data integrity of the database. It ensures that the application stores and retrieves data accurately and securely.

1. Structural Testing (Schema, Keys). 2. Functional Testing (CRUD operations). 3. Non-Functional Testing (Load, Security).

Verifying the structure of the database, including whether the tables, columns, data types, and constraints match the design documentation.

Ensuring that the data stored in the database is accurate and consistent. This involves checking if foreign key constraints, unique constraints, and NOT NULL rules are correctly enforced.

Testing that transactions follow ACID rules: Atomicity (all or nothing), Consistency (valid state), Isolation (sequential-like), and Durability (persisted).

I execute the stored procedure using a database client or automation script with various inputs and verify if the output and the resulting database changes match the expected requirements.

I perform the action that triggers the event (e.g., an INSERT or DELETE) and then query the affected tables to verify that the trigger executed its logic correctly.

QA engineers use SQL queries (SELECT, JOIN, WHERE) to fetch data from the database and compare it against the UI or API response to validate end-to-end data flow.

1. Perform the 'Create' action on the UI/API. 2. Run a `SELECT` query in the DB using the unique identifier. 3. Assert that all column values match the input.

1. Identify an existing record. 2. Perform 'Update' action. 3. Query the DB and verify the specific fields have changed while others remain the same.

I write queries using different JOIN types (INNER, LEFT, RIGHT) to ensure that the relationships between tables (Primary Key to Foreign Key) are functioning correctly and returning the expected data set.

I run performance-heavy queries and use the `EXPLAIN` command (in SQL) to verify if the database is utilizing the index instead of performing a slow full-table scan.

Testing performed when moving data from an old database system to a new one. It verifies that no data is lost, all data types remain compatible, and the application still functions correctly.

I use the JDBC (Java Database Connectivity) API. I load the driver, establish a connection using a URL, create a statement, and execute the query.

JDBC is a Java API used to connect and execute queries with a database. In automation, it is used to perform database assertions or to set up/tear down test data.

I create a utility class using JDBC. I use the `ResultSet` object to store the query result and then iterate through it to perform assertions against expected values.

Selenium cannot see the DB. I use a separate DB library (like JDBC for Java) within the same test script. I fetch a value from the UI using Selenium and then compare it with the value fetched from the DB using SQL.

ETL (Extract, Transform, Load) testing verifies that data is correctly extracted from sources, transformed according to business rules, and loaded into the target data warehouse in the correct format.

Testing of massive data repositories. It focuses on data completeness, data accuracy across multiple dimensions, and the performance of complex aggregation queries.

I use tools like JMeter (via JDBC Request Samplers) to simulate multiple users running queries simultaneously, monitoring the response time and server load.

CI (Continuous Integration): Merging code changes frequently into a shared repository. CD (Continuous Delivery/Deployment): Automating the release process to staging or production.

A development practice where developers integrate code into a shared repository multiple times a day. Each integration is verified by an automated build and automated tests to detect errors early.

Continuous Delivery means the code is always ready to be deployed, but requires a manual 'push' to production. Continuous Deployment means every change that passes all tests is automatically pushed to production without human intervention.

An open-source automation server used to build, test, and deploy software. It is the most popular tool for managing CI/CD pipelines.

I create a 'Build Job' in Jenkins. I configure it to pull code from Git, then run a command (like `mvn test` for Maven projects). Jenkins executes the tests on its server or a connected agent.

A suite of plugins which supports implementing and integrating continuous delivery pipelines into Jenkins. It uses a Jenkinsfile to define the entire lifecycle of the application as code.

1. Declarative: A simpler, more rigid syntax for beginners. 2. Scripted: Uses Groovy script, offering more flexibility and power for complex logic.

I use the 'Build Periodically' option with Cron syntax (e.g., `H 0 * * *` to run every night at midnight).

Using Webhooks. When a developer pushes code to GitHub/GitLab, the repository sends a signal to Jenkins to immediately start a new build and test run.

A CI/CD tool built directly into GitHub. It allows you to automate your workflow using YAML files located in the `.github/workflows` directory of your repository.

I create a YAML workflow file in the `.github/workflows` directory. This file defines the 'runner' (OS), the steps to install dependencies (e.g., `npm install` or `mvn install`), and the command to execute the test suite. It can be triggered by a 'push' or 'pull_request' event.

GitLab's built-in tool for software development through continuous methodologies. It uses a `.gitlab-ci.yml` file to manage pipelines, similar to GitHub Actions, but integrates more deeply with GitLab's container registry and security features.

A cloud-based CI/CD platform that automates the software development process. It is known for its speed and easy integration with GitHub/Bitbucket, using a `.circleci/config.yml` file to define build jobs.

Docker allows QA to package an application and its testing environment into a single container. This ensures that 'it works on my machine' applies everywhere, providing a consistent environment for test execution.

I use Selenium Grid Docker images or Zalenium. I spin up containers for the Hub and Nodes (Chrome/Firefox) using a `docker-compose.yml` file. My test script then points to the Dockerized Hub's remote URL.

A tool for defining and running multi-container Docker applications. For QA, it’s used to launch the app, its database, and the selenium grid nodes all at once with a single command: `docker-compose up`.

Kubernetes (K8s) is used to orchestrate test containers at scale. It handles auto-scaling of test pods and self-healing. For example, if a browser node crashes during a heavy load test, K8s automatically restarts it.

I split the test suite into multiple chunks and run them across multiple Jenkins agents or Docker containers simultaneously. This is combined with TestNG's parallel execution to drastically reduce total pipeline time.

The process of automatically generating and publishing test results to the CI tool dashboard. It allows stakeholders to see a visual summary of passes, failures, and trends without accessing the server logs.

A flexible, lightweight multi-language test report tool that shows a clear graphical representation of what was tested. It includes steps, logs, and screenshots of failures, making it a favorite for SDETs.

A library used in Selenium for generating interactive, beautiful HTML reports. It allows for custom logging, adding screenshots, and categorized test views.

By using specific plugins (like the Allure Jenkins Plugin or HTML Publisher Plugin). Once the build completes, the plugin parses the test output files (XML/JSON) and renders the report on the Jenkins job page.

Saving the files generated during the build/test process (like `.jar` files, logs, or screenshots) so they can be downloaded or reviewed later, even after the build workspace is cleared.

The management of infrastructure (networks, virtual machines, load balancers) in a descriptive model, using the same versioning as the DevOps team uses for source code. Examples include Terraform and CloudFormation.

An open-source IaC tool that allows you to define and provide data center infrastructure using a declarative configuration language. SDETs use it to spin up entire test environments automatically.

A QA Engineer focuses primarily on manual and automated testing, emphasizing user scenarios and defect discovery. An SDET (Software Development Engineer in Test) is a developer who focuses on testing; they build the tools, frameworks, and infrastructure used for automation.

Typically Java, Python, or JavaScript/TypeScript. These are the most common languages for automation tools like Selenium, Playwright, and Appium.

A programming paradigm based on the concept of 'objects', which can contain data (fields) and code (methods). It aims to organize code to make it reusable and easier to maintain.

1. Encapsulation: Bundling data and methods into a single unit (class) and restricting access. 2. Inheritance: One class acquiring properties of another. 3. Polymorphism: One interface having many forms (overloading/overriding). 4. Abstraction: Hiding internal details and showing only essential features.

It is the mechanism of wrapping data (variables) and code acting on the data (methods) together as a single unit. We use `private` variables and `public` getter/setter methods to control access.

The process where one class (child/subclass) inherits the members of another class (parent/superclass). It promotes code reusability using the `extends` keyword in Java.

Polymorphism means 'many forms'. It allows us to perform a single action in different ways. In Java, it’s achieved through Method Overloading (compile-time) and Method Overriding (runtime).

A process of hiding the implementation details and showing only the functionality to the user. For example, when you click 'Send' in an email app, you don't need to know the SMTP logic behind it. It's implemented via abstract classes and interfaces.

An Abstract Class can have both abstract and concrete methods and can maintain state (variables). An Interface (prior to Java 8) could only have abstract methods and is used to define a 'contract' that classes must implement.

1. Overloading: Same method name, different parameters in the same class. 2. Overriding: Same method name and parameters in parent and child classes (used in inheritance).

A special method used to initialize objects. It is called when an instance of a class is created. It has the same name as the class and no return type.

A constructor is used to initialize state; a method is used to represent behavior. Constructors don't have return types; methods do. Constructors are called implicitly on object creation; methods are called explicitly.

The `static` keyword means the member (variable or method) belongs to the class itself rather than to instances of the class. You can call static methods without creating an object.

Used to restrict the user. A `final` variable cannot be changed; a `final` method cannot be overridden; a `final` class cannot be inherited.

1. String: Immutable (cannot be changed). 2. StringBuilder: Mutable, not thread-safe (faster). 3. StringBuffer: Mutable, thread-safe (synchronized, slower).

1. ArrayList: Uses a dynamic array; better for storing and accessing data (fast search). 2. LinkedList: Uses a doubly linked list; better for manipulating data (fast insertion/deletion).

A part of the Collections framework that stores data in 'Key-Value' pairs. It allows for fast retrieval based on a unique key.

1. HashMap: Non-synchronized, allows one null key and multiple null values. 2. HashTable: Synchronized (thread-safe), does not allow null keys or values.

A mechanism to handle runtime errors (like `FileNotFoundException` or `ArithmeticException`) so that the normal flow of the application can be maintained using `try`, `catch`, `finally`, `throw`, and `throws`.

`try` block contains the code that might throw an exception. `catch` block handles the exception. `finally` block always executes, used for cleanup like closing DB connections.

1. Checked: Checked at compile-time (e.g., `IOException`). 2. Unchecked: Occur at runtime (e.g., `NullPointerException`).

`throw` is used to explicitly throw a single exception. `throws` is used in a method signature to declare that the method might throw one or more exceptions.

A unified architecture for representing and manipulating collections (Groups of objects). It includes interfaces like `List`, `Set`, `Map` and classes like `ArrayList`, `HashSet`, `HashMap`.

An object that can be used to loop through collections, like `ArrayList` and `HashSet`. It allows you to traverse and remove elements while iterating.

Iterator can traverse in the forward direction only. ListIterator can traverse in both forward and backward directions and can only be used with `List` types.

Introduced in Java 8, it provides a clear and concise way to represent one-method interface using an expression. It is very useful in collection libraries for filtering and mapping data.

Used to process collections of objects. A stream is a sequence of objects that supports various methods which can be pipelined (like `filter`, `map`, `reduce`) to produce the desired result.

A process of executing two or more threads simultaneously to maximum utilization of CPU. Each thread runs in parallel to others.

The capability to control the access of multiple threads to any shared resource. It prevents thread interference and memory consistency errors.

1. Thread: A class. Extending it means you can't extend any other class. 2. Runnable: An interface. Implementing it allows you to still extend another class. Runnable is generally preferred.

The ability to understand the internal state of a test execution by looking at the data it produces (logs, traces, metrics). It goes beyond simple pass/fail to explain *why* something happened.

The discipline of experimenting on a software system in production in order to build confidence in the system's capability to withstand turbulent and unexpected conditions (like killing a random server).

Testing that ensures that a provider (service providing data) and a consumer (service receiving data) are compatible and can communicate correctly based on a shared contract.

An open-source consumer-driven contract testing tool. It allows you to define a contract on the consumer side and then verify it on the provider side.

A technique that simulates the behavior of specific components (like a 3rd party API) that are unavailable or difficult to access during testing.

Shift-left is the practice of moving testing earlier in the software development lifecycle. Instead of waiting for a complete build, QA participates in requirement reviews, design discussions, and starts writing automation scripts alongside development to catch bugs when they are cheapest to fix.

TDM is the process of planning, creating, storing, and delivering the data required for automated and manual testing. It ensures that tests have the necessary state (e.g., specific user types, balances) without relying on fragile, manual setup.

I use Data Masking or Data Obfuscation to replace PII (Personally Identifiable Information) with realistic but fake data. In regulated industries, I ensure that production data is never directly used in test environments to comply with GDPR or HIPAA.

Synthetic monitoring (or directed monitoring) uses automated scripts to simulate user paths through an application at regular intervals. It helps monitor performance and availability in production before real users report issues.

Canary testing is a deployment strategy where a new code version is rolled out to a small subset of real users (the 'canary') before making it available to the entire population. QA monitors logs and metrics on this group for errors.

A strategy where two identical production environments exist (Blue and Green). Only one is live. QA tests the new version in the idle environment; if it passes, the load balancer flips traffic to it, providing zero-downtime releases.

Testing functionality that is wrapped in a 'toggle'. It allows QA to test features in production by enabling the flag only for internal test accounts, while keeping the feature hidden from the general public.

Mutation testing involves making small, intentional changes ('mutants') to the application source code (e.g., changing `>` to `<`). If the existing test suite still passes, it means the tests are weak and failed to 'kill' the mutant.

Instead of testing specific inputs, property-based testing defines properties that should always be true (e.g., 'sorting an array shouldn't change its length'). The tool then generates hundreds of random inputs to try and falsify these properties.

A technique that focuses on the 'look and feel' by comparing pixel-by-pixel snapshots of the UI against a baseline. It catches CSS bugs, alignment issues, or color changes that functional tests would ignore.

1. Positive: Exact matches, partial matches. 2. Negative: No results found, special characters, SQL injection attempts. 3. UI: Autocomplete, pagination, clearing results. 4. Performance: Load time for large datasets.

I test the 'Happy Path' (Login -> Add to Cart -> Valid Payment -> Success). Then I test edge cases: items going out of stock mid-checkout, expired credit cards, invalid promo codes, and guest checkout vs. logged-in users.

I use sandbox/test card numbers provided by the gateway (like Stripe). I verify: 1. Successful payment. 2. Declined payment (wrong CVV, insufficient funds). 3. Refund processing. 4. Callback/Webhook updates to the order status.

I test various file types (PDF, PNG, JPG), file size limits (max size and 0 byte files), multiple file uploads, and security (uploading an executable file to check for server-side blocking).

I verify the total count matches the sum of items across pages. I check the 'Next', 'Previous', 'First', and 'Last' buttons, and verify that changing the 'Items per page' (e.g., 10 to 50) updates the UI correctly.

I use a scroll-to-bottom action in automation. I verify that new content loads without duplicates, the 'loading' spinner appears/disappears, and that the browser doesn't crash or slow down significantly as the list grows.

1. Functional: Addition, Subtraction, Multiplication, Division. 2. Boundary: Max/Min values, dividing by zero. 3. Memory: 'Clear' and 'Memory Recall' functions. 4. Usability: Scientific notations and decimal precision.

I use tools like Mailtrap or Mailosaur. I verify that the email is triggered, reaches the inbox, contains the correct HTML/Text content, and that all links inside the email (like 'Verify Account') are functional.

Check field validations (mandatory vs. optional), data formats (valid email/phone), password strength indicators, duplicate account detection, and successful redirection after submission.

Verify the link is sent only to registered emails, the link has a short expiration time, the link is one-time use only, and the user is logged out of all other active sessions after the reset.

Perform sorting on various columns (Ascending/Descending). Verify the order by comparing the UI list against a sorted copy of the data. Test sorting on strings, numbers, and dates.

Apply single and multiple filters simultaneously. Verify that 'No results' is displayed if no match is found, and that 'Clear Filters' returns the list to its original state.

Select today, past dates, and future dates. Verify date range selections, disabling of invalid dates (e.g., selecting a checkout date before check-in), and localization (MM/DD/YYYY vs DD/MM/YYYY).

Verify that data is saved after a specific interval or trigger. Test by interrupting the process (closing tab, losing internet) and ensuring data is recovered upon reopening.

Use two sessions. Trigger an action in Session A and verify that Session B receives the notification instantly via WebSockets without needing a page refresh.

Test intent recognition (asking the same thing in different ways), fallback responses (handling unknown questions), and the ability to hand off to a human agent.

Verify Play/Pause/Seek functions, auto-resolution switching based on bandwidth, proper loading of subtitles, and behavior when the internet is disconnected and reconnected.

Verify marker placement based on coordinates, zoom levels, panning, and 'Get Directions' logic which should open the native map app or a routing service.

Use GPS Spoofing or mocking in the browser/mobile driver to simulate being in different cities or countries to verify region-locked content or distance calculations.

I would use the Page Object Model to build a script that spans multiple modules: Login -> Search -> Cart -> Payment -> Confirmation, asserting the state at each step.

I use Setup/Teardown methods. If Test B needs a user created by Test A, I create that user via an API call in the `@Before` method of Test B to ensure independence.

By executing simultaneous requests (e.g., two users trying to buy the last item in stock at the exact same time) and verifying the system handles concurrency via database locks.

Use Profilers (like Chrome DevTools or JProfiler). I run a specific user scenario repeatedly and monitor if the 'Heap Size' continues to grow without returning to the baseline.

I use Mocks or Service Virtualization (WireMock) to simulate the third party during local testing, and use dedicated 'Sandbox' environments for end-to-end integration testing.

I use APIs provided by services like Twilio or Mailosaur to programmatically 'fetch' the last message sent to a number/address and then parse the content for verification.

I reduce the timeout limit in the test environment to a short duration (e.g., 1 minute). I then wait for that time and verify the user is redirected to the login page on the next action.

I use tools like JMeter or K6 to simulate many users performing the same action simultaneously to check for database deadlocks or server crashes.

Compare record counts before and after migration. Use SQL scripts to verify that data mapped correctly to new schemas and that no PII was leaked or corrupted during the process.

I trigger specific error states (wrong password, empty field) and assert that the error text matches the requirements, is properly colored (red), and is accessible to screen readers.

Verify the data source (API/DB) matches the chart values. Test filtering/date range updates, 'No Data' states, and responsiveness when the window is resized.

Focus on relevance (ranking), latency (results in ms), support for 100+ languages, handling of special characters, and the 'Did you mean' suggestion engine logic.

Verify rerouting when a turn is missed, accuracy of ETA based on real-time traffic data, offline map functionality, and voice command clarity during high-speed travel.

Test with known phishing patterns, emails with suspicious attachments, mass-sent marketing emails, and 'False Positives' (ensuring legitimate emails from new contacts aren't marked as spam).

Verify different formats (.mp4, .mov), resolution processing (up to 8K), copyright detection (Content ID), and background uploading behavior when the app is minimized.

Test granular permissions (Viewer, Commenter, Editor), link expiration, revoking access in real-time, and notifications sent to the recipient.

I would use a tool that supports complex grid interactions (like Playwright). Focus on formula recalculation across cells, concurrent editing by 10+ users, and version history.

Focus on Backward Compatibility. Ensure that the new version doesn't break popular websites or stored user data (cookies, bookmarks, history) from the previous version.

Verify multi-device synchronization (phone vs. desktop), time-zone handling for travelers, and triggering of push, email, and desktop notifications at the exact set time.

Verify ad-relevance to search queries, correct billing for 'Cost Per Click', visual rendering on various screen sizes, and strict blocking of prohibited ad content.

Simulate high-concurrency API calls to compute/storage engines. Monitor 'Auto-scaling' behavior to ensure new instances spin up before the current ones reach 90% CPU load.

Focus on indexing speed (how fast new products appear), search relevance (ranking), filter accuracy (price, prime, rating), and performance during high-traffic events like Prime Day.

Verify adding/removing items, quantity updates, persistence across devices, moving items to 'Save for Later', and handling price changes while items are in the cart.

Test default payment/address settings, immediate order generation, the 30-minute 'cancellation window', and ensuring that concurrent one-clicks don't result in duplicate shipments.

Verify DRM (Digital Rights Management) compliance, adaptive bitrate switching, regional licensing restrictions (Geo-fencing), and cross-device playback resume.

Focus on Natural Language Processing (NLP) for various accents, ambient noise interference, wake-word sensitivity, and the accuracy of the intent-response mapping.

Verify 'Frequently Bought Together' logic based on cart history, ensuring recommendations update after a purchase, and checking for diversity in suggested items.

Verify the integration between logistics partners and the UI, status transitions (Shipped -> Out for Delivery), and the 'Map' view accuracy for real-time delivery tracking.

Verify wallet balance updates, refund processing times, payment security (2FA), and successful integration with third-party merchant sites.

Test barcode scanning accuracy, inventory decrement/increment logic, automated shelf-picking robot synchronization, and real-time inventory alerts.

Run distributed load tests to simulate 100x normal traffic. Monitor database lock contention, auto-scaling latency, and payment gateway response times under extreme stress.

Test the ranking algorithm (relevance), media rendering (auto-play videos), infinite scroll performance, and 'New Post' notification badges without refreshing the page.

Test media upload quality, 24-hour expiration logic, viewer list accuracy, and interactive elements like polls/stickers.

Verify 'Mutual Friends' count accuracy, logic for suggesting contacts from synced phonebooks, and ensuring that 'removed' suggestions do not reappear immediately.

Verify End-to-End Encryption (E2EE) by intercepting network traffic to ensure data is unreadable, and testing 'Change Security Code' notifications when a contact switches devices.

Test latency between streamer and viewer, real-time comment synchronization, and the 'reconnecting' logic during network fluctuations.

Verify that ads match user interests/demographics, ad-delivery frequency (capping), and the accuracy of the 'Why am I seeing this?' diagnostic tool.

Test AI-flagging of prohibited keywords/images, user reporting flows, and the 'appeals' process for reinstated content.

Verify location-based search, image upload limits, buyer-seller messaging, and 'Sold' status updates.

Test delivery/read receipts for multiple recipients, group admin permissions, and performance when 100+ users message simultaneously.

Focus on WebSocket connection stability, load balancing across global regions, and database read-replica lag during viral events.

Verify the 'buffer' logic, audio-video synchronization, 4K/HDR rendering support, and seamless transition between episodes in 'Binge' mode.

Verify 'Because you watched' categories, accuracy of 'Top 10 in your country', and ensuring the 'Dislike' button successfully hides content from future suggestions.

Test storage limit handling, expiration of downloaded content (license management), and playback functionality without any network connection.

Verify subtitle alignment with audio across different playback speeds, support for special characters in 20+ languages, and visual legibility against various backgrounds.

Verify independent watch-histories for each profile, 'Kids' profile restrictions, and profile-locking with PINs.

Verify that age-restricted content is blocked on profiles with parental controls and that rating stars/thumbs correctly reflect the user's input.

Simulate bandwidth drops (e.g., 50Mbps to 2Mbps) and verify that the player downgrades resolution without stopping the video (no buffering spinning).

Verify PIN requirements for specific maturity levels, blocking specific titles globally for a profile, and log-out synchronization across all devices.

Test by actor, genre, or specific quotes. Verify 'Coming Soon' results and 'Explore Titles related to...' suggestions when a specific movie is unavailable.

Simulate 'Global Release' spikes (e.g., Stranger Things). Test the API gateway's ability to handle millions of 'start-play' events simultaneously.

Verify pickup/destination selection, price estimation accuracy, matching with nearest driver, and successful dispatch notification.

Verify that a driver who 'declines' isn't re-offered the same ride instantly, and that the rider is matched with the next optimal driver based on ETA.

Verify multiplier calculation based on real-time demand/supply in a specific geofence and ensure the rider is notified of the multiplier before booking.

Verify marker movement smoothness on the map, accuracy of 'minutes away' countdown, and handling of GPS signal loss in tunnels.

Test credit card, digital wallets, and cash options. Verify 'Auth Hold' at the start and 'Final Capture' at the end of the trip including tips.

Verify cancellation fee logic based on time elapsed, driver notification, and rider's ability to provide a reason for cancellation.

Verify that 1-star ratings prompt for feedback, average rating updates in the DB, and 'Low Rating' triggers internal quality warnings for drivers.

Verify restaurant-to-customer distance limits, 'Estimated Arrival' updates from the restaurant side, and multi-order batching for drivers.

Verify the 'Uber Share' logic (picking up a second rider on a compatible path) and ensuring the driver's navigation app uses the most efficient route.

Simulate massive concurrent ride requests and GPS pings. Test system resilience when 3rd party map APIs or payment processors experience high latency.

Focus on background blur/replacement accuracy, screen sharing latency, 'Hand Raise' notification sync, and noise cancellation for keyboard typing.

Test complex nested formulas, circular reference detection, calculation accuracy for extremely large numbers, and cross-sheet cell dependencies.

Test 'Differential Sync' (only uploading changed parts), conflict resolution when two users edit the same file offline, and 'Files on Demand' logic.

Focus on 'Rollback' functionality if an update fails, ensuring minimal system interruption, and verifying driver compatibility with new OS patches.

Verify 'Focused Inbox' categorization, calendar invite synchronization, attachment size limits, and 'Undo Send' delay functionality.

Test VM provisioning time, Load Balancer failover, Blob storage availability across regions, and IAM (Identity Access Management) security.

Verify animation trigger timing, hardware acceleration performance on low-end PCs, and consistent rendering across Export formats (PDF/Video).

Verify app download/install/update cycles, regional pricing/currency support, and license verification for paid apps.

Focus on multiplayer matchmaking latency, achievement unlocking synchronization, and parental control enforcement for voice chat.

Test real-time co-authoring in Word/Excel under high user concurrency and latency. Monitor cloud-save success rates during unstable network conditions.

Verify blue vs. green bubble logic (iMessage vs. SMS), end-to-end encryption, synchronization across macOS/iOS/watchOS, and the 'Undo Send' or 'Edit Message' time-window constraints.

Test unlocking with accessories (glasses, masks), varying lighting conditions (pitch black vs. sunlight), 'Attention Awareness' logic, and the transition to passcode entry after five failed attempts.

Verify automatic backup triggers during charging/Wi-Fi, data restoration accuracy on a new device, and 'Storage Full' notifications when the 5GB free tier limit is reached.

Verify compliance with Apple's strict Privacy Manifests, in-app purchase (IAP) flow, and ensuring the app doesn't use private APIs that would lead to rejection.

Focus on 'Offline Siri' for system commands (alarms, timers), accuracy of 'Hey Siri' wake-word detection across distances, and integration with third-party apps via SiriKit.

Verify 'Double Click to Pay' logic, NFC communication with point-of-sale terminals, Express Transit mode (paying without waking the phone), and privacy (DAN vs. actual card number).

Verify peer-to-peer Wi-Fi/Bluetooth handshakes, 'Everyone' vs. 'Contacts Only' visibility, and handling of interrupted transfers when devices move out of range.

Verify 'Update Tonight' scheduling, storage space optimization (unloading apps temporarily), and the thermal management behavior during the high-CPU installation phase.

Verify Lossless/Spatial Audio playback, 'Siri, play something I like' algorithm accuracy, and synchronization of the 'Library' across the ecosystem.

Test 'Shutter Lag' (time from tap to capture), 'Cold Start' time to ensure the user doesn't miss a moment, and thermal throttling during long 4K 60fps video recording.

Verify seamless switching between 'Low', 'Normal', 'High', and 'Very High' bitrates, and the gapless playback transition between tracks in an album.

Verify adding/removing tracks, playlist cover art customization, 'Enhance' button logic for song suggestions, and 'Public' vs. 'Private' visibility settings.

Verify that only downloaded tracks are playable, 'Greyed out' UI for unavailable tracks, and that local playback doesn't consume mobile data.

Verify 'Discover Weekly' updates every Monday, 'Daily Mix' diversity, and the 'Don't play this artist' feature impact on global suggestions.

Verify real-time updates when a friend adds a track, 'User Avatars' appearing next to added songs, and permission logic for the playlist owner.

Verify 'Mark as Played' logic, variable speed playback (0.5x to 3x), 'Sleep Timer' accuracy, and downloading of specific episodes.

Verify real-time scrolling of lyrics with the audio, 'Share Lyric' card generation, and handling of instrumental breaks.

Verify 'Handover' from phone to smart speaker, volume control synchronization across devices, and the 'Group Session' remote control logic.

Verify 'Top Result' accuracy, fuzzy matching for typos, and the speed of results appearing as the user types (latency).

Simulate massive traffic to the 'Live Events' tab. Verify that the integration with ticket partners (Ticketmaster) doesn't crash the Spotify app.

Verify 'Remote' vs. 'On-site' filters, 'Easy Apply' functionality, 'Salary' range accuracy, and saving search alerts for new job postings.

Verify the 'Personalized Note' character limit, 'Pending' status logic, and ensuring that 'Ignored' requests don't allow immediate re-sending.

Verify 'Typing Indicators', 'Read Receipts', 'InMail' credit consumption for Premium users, and 'Attachment' size/type restrictions.

Verify 'People also viewed' logic, 'Skills' suggestions based on job title, and the accuracy of the 'Who's viewed your profile' counter.

Verify 'Reactions' (Like, Celebrate, Love), comment threading, 'Share' count updates, and the visibility logic for 'reposted' content in the feed.

Verify 'Application Submitted' status updates, the 'Resume' upload persistence, and the 'Viewed by Recruiter' notification triggers.

Verify 'Certificate' generation upon course completion, progress tracking across sessions, and 'Offline' viewing on the mobile app.

Verify 'Employee' count accuracy based on user profiles, 'Life' tab media rendering, and the 'Analytics' dashboard for page admins.

Verify 'Private Mode' browsing, access to 'Business Insights' on company pages, and the 'Top Applicant' badge visibility for relevant jobs.

Simulate peak morning traffic (9 AM). Test the feed's ability to serve personalized content to 100M+ users simultaneously without high latency.

Verify 'Map' vs. 'List' view sync, price range slider accuracy, 'Superhost' filter logic, and the 'Total Price' (including cleaning fees) display.

Verify 'Greyed out' unavailable dates, 'Minimum Stay' requirements (e.g., 2 nights), and ensuring that 'Pessimistic Locking' prevents double-booking.

Verify that each guest's card is charged correctly, 'Pending' status until everyone pays, and the automatic cancellation/refund if the group fails to pay within 24h.

Verify 'Auto-translation' features, 'Quick Replies' for hosts, and the blocking of PII (phone numbers/emails) before a booking is confirmed for security.

Verify that reviews can only be left *after* a stay, 'Average Rating' calculation accuracy (Cleanliness, Accuracy, etc.), and 'Host Response' visibility.

Verify 'Weekend' vs 'Weekday' rates, 'Last minute' discounts, and host-defined 'Custom' prices for specific holidays.

Verify 'Flexible', 'Moderate', and 'Strict' refund calculations based on the time remaining before check-in.

Verify 'Wishlist' item similarity, 'Similar Listings' suggestions at the bottom of a property page, and 'Recently Viewed' history.

Verify the bypass of 'Host Approval' flow, immediate reservation generation, and ensuring the host's 'Booking Requirements' (e.g., ID verified) are met first.

Simulate New Year's Eve search volume. Monitor database performance for 'Availability' queries and payment gateway success rates during peak minutes.

Describe the situation using the STAR method. Explain the technical impact (e.g., data leak), how you isolated it, and the steps taken to prevent it from happening again.

Focus on 'Data over Emotion'. Show how you use the requirements doc or logs to prove a point, while remaining professional and open to the developer's technical constraints.

Explain the process: 1. Understand requirements. 2. Create Test Plan/Cases. 3. Risk-analysis. 4. Smoke -> Functional -> Regression -> UAT. 5. Bug reporting and closure.

Use 'Risk-Based Testing'. Prioritize high-business impact and high-failure probability modules. Focus on 'P0' Smoke and Regression suites first.

Discuss a scenario involving multi-threading, OTP bypassing via API, or complex database validation, highlighting the 'Efficiency' and 'Time saved' for the team.

1. Triage: Verify severity. 2. Hotfix support: Test the fix in staging. 3. Root Cause Analysis (RCA): Document why the bug was missed and add an automation test to cover it.

Be honest about flaky tests or high maintenance. Explain the lesson learned (e.g., moving from XPath to ID, or adding better Explicit Waits).

Present an 'ROI Analysis'. Show the time taken for manual regression vs. automation execution. Start with a small 'Proof of Concept' (POC).

1. Stable locators. 2. Intelligent waits. 3. Clean test data setup. 4. Quarantining failing tests for analysis instead of ignoring them.

Discuss 'Continuous Testing'. Integrate automation in the CI/CD pipeline to catch bugs early, allowing for faster releases without compromising quality.

Explain how you collaborated with Product Managers (PMs), looked at competitors' products, and used exploratory testing to define the 'Expected Behavior'.

Stay organized. Use task-tracking tools (Jira). Communicate clearly about progress and risks. Focus on critical 'Blockers' first.

Mention reading documentation, building a small 'Pet Project', joining community forums (StackOverflow), and sharing knowledge with the team.

Pair testing, code reviews for their automation scripts, sharing 'Testing Mindsets', and encouraging them to take ownership of specific modules.

1. Defect Leakage (production bugs). 2. Test Execution Pass/Fail rate. 3. Automation Coverage. 4. Mean Time to Detect (MTTD).

I test the app with the flag 'ON' and 'OFF' to ensure the fallback logic works. I verify the flag works for specific user IDs/segments in production.

I refer back to the PRD (Product Requirement Document). If it's ambiguous, I pull in the Product Manager to clarify the user intent.

I use masked data, never use real production passwords, and ensure test environments are behind the company VPN/Firewall.

Maybe you introduced 'Pre-Dev QA' (Shift-Left) or automated the generation of test data, reducing the setup time by 50%.

I work with DevOps to scale the infrastructure, run massive 'Stress' tests, and implement 'Circuit Breakers' to save the core system if a sub-service fails.

I use 'BrowserStack' or 'LambdaTest' for a cloud grid. I focus on CSS Grid/Flexbox rendering and JS compatibility on Safari (macOS) vs. Chrome (Windows).

I check the logs (Logcat/CloudWatch), verify the exact environment (browser version, network speed), and ask the reporter for a video/screen recording.

It's a goal, not a reality. I prioritize 'Zero-Blocker' and 'Zero-Critical-Bug' policies. Some minor UI bugs might be deferred to maintain release speed.

By using Page Object Model (POM), keeping methods small and 'Atomic', using meaningful naming conventions, and documenting complex logic.

The ability to bridge the gap between user quality and code logic, and the satisfaction of building tools that make the entire engineering team faster and more confident.