QA and testing interview questions

What testing gives a project

Why "the earlier, the cheaper": a mistake in a requirement gets copied into the design, the code and the test cases, and must then be fixed in all of them. Found in production, it also brings support calls, an emergency release and damage to the brand. The multipliers people quote, such as "10 times more per phase", are rough rules of thumb, but the direction holds.

The seven testing principles come up as follow-ups often enough to know by name. In the current ISTQB syllabus they are:

1. Testing shows the presence, not the absence, of defects.
2. Exhaustive testing is impossible, so we prioritise.
3. Early testing saves time and money.
4. Defects cluster together: a few modules hold most of them.
5. Tests wear out: repeating the same tests stops finding new bugs (once called the pesticide paradox).
6. Testing is context dependent: a banking app and a game need different testing.
7. The absence-of-defects fallacy: a bug-free product that doesn't meet users' needs is still a failure.

Follow-ups

• QA vs QC vs testing? Quality assurance improves the process to prevent defects (standards, reviews, audits); quality control checks the product to find them; testing is the main quality-control activity.
• Can testing prove software is bug-free? No. That's principle 1: it reduces the risk of undiscovered defects, it doesn't remove it.

On a food delivery app

• Verification: reviewing the requirement "orders under ₹199 pay a ₹30 delivery fee" against the design and the code, and spotting that the code uses <= instead of <.
• Validation: placing a real ₹150 order on the test build and checking the fee charged is ₹30, then letting users try it in acceptance testing.

A nuance worth one sentence: strictly, some verification also runs code, such as unit tests checked against a design. But the static vs dynamic split is the answer interviewers expect, so lead with it.

Follow-ups

• Can a product pass verification but fail validation? Yes. It can match its specification perfectly while the specification describes the wrong thing, like a beautifully built report nobody needs.
• Where do they sit in the V-Model? Verification activities run down the left side, validation (test execution) up the right side (question 4).

One chain, end to end

Note that only one input, exactly ₹499, triggers this failure. That's why testers test boundary values (question 15).

Why the distinction matters

• A defect can sit unnoticed for years if its code never runs with the triggering data, such as date logic that only fails on 29 February.
• Testing finds failures; developers then debug to find the defect behind them; a root-cause analysis looks for the error that let it in (question 24).

Follow-ups

• Is "bug" an official term? It's the everyday word for a defect; ISTQB treats bug, defect and fault as synonyms.
• Can a failure happen without a defect? Yes: environmental conditions, such as a server running out of memory or radiation flipping a bit, can cause failures in correct code.

The SDLC phases and what each produces

Some sources add a separate planning phase at the start; the order is what matters.

Waterfall: one straight line, each phase signed off before the next.

Requirements → Design → Development → Testing → Deployment → Maintenance

The V-Model: development goes down the left side; each phase has a matching test level on the right, planned at the same time.

Requirements ──────────────────────────────── Acceptance testing
    System design ──────────────────── System testing
        Architecture design ──── Integration testing
            Module design ── Unit testing
                      Coding

Follow-ups

• When is Waterfall still a fair choice? For short projects whose requirements genuinely won't change, or where regulations demand sign-off at each phase.
• How does Agile differ? It repeats a small cycle of all these phases every sprint, so testing happens continuously (question 7).

Environment setup often runs in parallel with test case development, since different people usually handle them.

Entry and exit criteria are the conditions to start and finish a phase. Typical exit criteria for execution:

• All planned test cases executed, and every critical case passed.
• No open blocker or critical defects; any open major ones accepted by the product owner.
• Regression suite passed on the final build.

Phase names vary between sources: some call phase 3 "test design", or merge closure into reporting. Interviewers care that you know the flow and what each step produces.

Follow-ups

• SDLC vs STLC? The STLC is the testing part of the SDLC. It starts as soon as requirements exist, not when coding ends.
• What if the exit criteria aren't met by the release date? Report the gap and the risk; the product owner decides whether to ship, delay or cut scope (question 8).

What a test plan contains, for a release adding UPI refunds

This outline comes from the IEEE 829 standard, since replaced by ISO/IEC/IEEE 29119-3, but it's still the one most teams and interviewers use. In Agile teams, the plan is often a single wiki page per release.

Follow-ups

• Who reviews a test plan? The project manager, product owner and development lead, so the scope and schedule are agreed before testing starts.
• Is a test plan needed in Agile? Usually a lighter one: sprint-level testing goes into the stories, and a short release plan covers environments, risks and regression.

Acceptance criteria a tester helps write

Story: As a shopper, I want to apply a coupon so that I pay less.

Given a cart worth ₹1,200
When Asha applies coupon SAVE10
Then the total becomes ₹1,080
And the message "Coupon applied" appears

Given a cart worth ₹400
When Asha applies coupon SAVE10
Then the total stays ₹400
And the message "Add ₹100 more to use this coupon" appears

This Given/When/Then style comes from behaviour-driven development, and each criterion becomes at least one test.

A typical Definition of Done: code reviewed, unit tests passing, acceptance criteria tested, no open critical defects, regression updated, deployed to staging.

Shift-left means moving testing earlier: reviewing requirements, testing APIs before the UI exists, and running automated tests on every commit. Each defect found earlier is cheaper to fix (question 1).

Follow-ups

• Who owns quality in Scrum? The whole team. The tester brings testing skills, but developers write unit tests and the team agrees the Definition of Done.
• What if stories always reach testing on the last day? Raise it in the retrospective: split stories smaller, and test each piece as soon as it's done.

Step by step

1. Smoke test the build. If it fails, nothing else matters: report it immediately.
2. List what changed. Release notes, merged tickets and the code diff show where new defects are most likely.
3. Rank areas by risk: how likely they are to break, multiplied by how much damage a failure would do.
4. Test from the top of the list and run the automated regression alongside.
5. Report clearly before the go/no-go meeting.

The status note matters as much as the testing

Release 2.5 test status (27 Oct, 6 p.m.)
Tested: payments, refunds, checkout, coupons; automated regression 312/315 passed.
Open: 1 major defect, a coupon message cut off on small screens (SHOP-244).
Not tested: profile photo upload, notification settings (unchanged since 2.4).
Recommendation: OK to release if SHOP-244 is accepted; test the skipped areas on Monday.

Follow-ups

• Would you ever recommend not releasing? Yes, if a blocker or critical defect is open in a core flow. The decision belongs to the product owner, but the recommendation should be clear.
• What happens after the release? Test the skipped areas first, and watch production errors and support tickets closely for a few days.

On a food delivery app, build 2.4.0

• Smoke: the app opens, a user can log in, search for a restaurant, add an item, and pay with a test card. Ten minutes, all critical paths, nothing in depth.
• Sanity, after a fix for "coupon not applied": apply SAVE10, check the total, remove the coupon, apply an expired one. Just the coupon area.

Why the terms get muddled: the ISTQB glossary lists sanity test as a synonym for smoke test, while many teams use the distinction above. In an interview, give the common usage and mention that some teams use the words interchangeably.

Follow-ups

• Is smoke testing part of regression? It's a small, fast subset of the most critical regression checks, run first so a broken build doesn't waste anyone's time.
• Who runs them? Smoke tests often run automatically in the CI pipeline on every build (question 40); a tester usually does the sanity check on a fix.

One fix, both activities

Bug SHOP-231, "Coupon SAVE10 isn't applied to carts above ₹1,000", has been fixed in build 2.4.1.

• Retesting: repeat the exact steps and data from the bug report on build 2.4.1. The total now drops by 10%, so the bug is verified.
• Regression: check what the fix could have disturbed: other coupons, carts at exactly ₹1,000, the payment amount, GST on the invoice, and order history.

Follow-ups

• Which comes first? Retesting. There's little point running a long regression on a build where the fix itself doesn't work.
• How do you choose regression scope when time is short? By risk: the changed module, the features that depend on it, and the critical business flows (question 8).

Integration approaches, a common follow-up:

• Big bang: combine everything at once and test. Simple, but failures are hard to trace.
• Top-down: start from the top modules and replace missing lower ones with stubs, which return canned answers.
• Bottom-up: start from the lowest modules and call them through drivers, small test programs standing in for the callers.
• Sandwich (hybrid): both directions at once.

Kinds of acceptance testing: alpha testing is done by internal users at the developer's site; beta testing by real customers in their own environment before general release.

Follow-ups

• Stub vs driver? A stub stands in for a module being called; a driver stands in for the module doing the calling.
• Where do API tests fit? Mostly at the integration and system levels: they check services working together without the UI.

White-box in practice: statement vs branch coverage

double finalPrice(double price, boolean hasCoupon) {
    if (hasCoupon) {
        price = price - 50;
    }
    return price;
}

The single test finalPrice(500, true) runs every statement, so it reaches 100% statement coverage, but it only takes the true branch of the if: 50% branch coverage. Adding finalPrice(500, false) covers both branches. Branch coverage is the stronger measure.

Grey-box in practice: after placing an order through the UI, you query the orders table to check the status is PLACED and the amount matches, because you know how the data is stored.

Follow-ups

• Which kind do testers do most? Black-box. White-box testing mostly happens through developers' unit tests and code coverage reports.
• Is grey-box just a mix of the other two? In practice, yes: black-box tests designed with a little knowledge of the internals.

Functional testing types you'll hear: unit, integration, system, smoke, sanity, regression and acceptance testing. Non-functional: performance (load, stress, spike, endurance; question 39), security, usability, compatibility, accessibility and localisation.

Why non-functional requirements need questions: they're often missing from the specification. A tester should ask how fast is fast enough, how many users to expect, and which browsers and devices matter, then turn the answers into measurable targets.

Follow-ups

• Is accessibility functional or non-functional? Usually classed as non-functional, a quality attribute, though laws and contracts can make it a hard requirement.
• Can the same test be both? One session can cover both, but the checks differ: "the transfer works" is functional; "it completes in under 2 seconds" is non-functional.

First, ask a few questions: how many failed attempts trigger a lockout, and for how long? What are the password rules? How long does "Remember me" last? Which browsers and devices matter? Good testers clarify before writing cases.

One case written in full: this is what a test management tool, or an interviewer asking for "one detailed case", expects.

ID:            TC04
Title:         Login fails with a wrong password
Priority:      High
Preconditions: User [email protected] exists and isn't locked
Steps:         1. Open https://staging.example.com/login
               2. Enter [email protected] in Email
               3. Enter Wrong@123 in Password
               4. Click "Log in"
Expected:      "Invalid email or password" appears; user stays on the login page;
               the failed-attempt count goes up by one

Positive vs negative testing: positive tests use valid inputs and check the system works; negative tests use invalid or unexpected inputs and check it fails gracefully, with a clear message and no crash.

Follow-ups

• Why the same message for a wrong password and an unknown email? A different message tells an attacker which emails are registered.
• What would you test that isn't functional? Load time, behaviour on slow networks, keyboard-only use and screen-reader labels, HTTPS, and rate limiting against password guessing.

Step 1: the partitions

Step 2: the boundaries

  too young           │            valid            │        too old
 …  16   17           │   18   19   …   59   60     │   61   62  …
                lower boundary                upper boundary

This answer uses two-value BVA; the ISTQB syllabus describes both, so say which one you're using.

Why boundaries matter: one value catches the bug

static boolean isValidAge(int age) {
    return age > 18 && age <= 60;     // bug: should be age >= 18
}

// isValidAge(35)  -> true   the partition value passes, so EP alone misses the bug
// isValidAge(18)  -> false  only the boundary value exposes it
// isValidAge(17)  -> false
// isValidAge(60)  -> true
// isValidAge(61)  -> false

The final set, two-value BVA plus the invalid-type partitions: 17, 18, 60, 61, 25.5, abc, blank and -5. The boundary values already cover the three numeric partitions (17 is too young, 18 and 60 valid, 61 too old), so 10, 35 and 75 add little; many testers still include 35 as a "typical" value.

Follow-ups

• What if the age is picked from a dropdown? The UI can't send invalid values, but the API behind it still can, so test the boundaries there (question 37).
• What's a decision table? A black-box technique for combinations of conditions, such as "member and cart above ₹1,000", where each column of the table becomes a test.

One scenario, several cases

Scenario TS-05: Check that a shopper can apply a coupon at checkout.

Related terms: a test script is a test case written as code; a test suite is a group of test cases run together, such as "checkout regression".

Follow-ups

• Do Agile teams still write detailed test cases? Often only for regression and critical flows; elsewhere they work from scenarios, checklists and the acceptance criteria.
• What makes a good test case? One clear objective, exact data, and an expected result that leaves no room for opinion.

The last row is the point of the exercise: REQ-104 has no test, and the RTM makes that gap impossible to miss.

Where it lives: a spreadsheet in small teams; in larger ones, links between Jira stories and test management tools such as Xray, Zephyr or TestRail build it automatically. It's started in the requirement analysis phase of the STLC and updated through execution (question 5).

Follow-ups

• How does an RTM help when a requirement changes? Find the requirement's row, and you have the list of test cases to update and rerun.
• Is 100% requirement coverage enough? No. It proves each requirement has a test, not that the tests are good; a single happy-path case "covers" a requirement too.

Where expected behaviour hides

Questions worth asking

• Who will use it, and what problem does it solve for them?
• What inputs are allowed, and what are the limits?
• What should happen when something goes wrong?
• Which platforms, browsers and roles are in scope? What's explicitly out of scope?

Exploratory testing with charters: time-boxed sessions, each with a mission, such as "Explore coupon entry with unusual codes, for 45 minutes, to discover how validation works." Note what you find, then turn it into scenarios.

The deliverable: a short list of scenarios and assumptions, such as "Assumption: coupon codes aren't case-sensitive", sent to the product owner to confirm. Once confirmed, it becomes the requirement you test against.

Follow-ups

• How would you test a pen? The same skill: ask first (what kind of pen, for whom, for what), then cover function (it writes, the ink flows), limits (paper types, temperatures), durability (drops, clicks) and negative cases (writing upside down).
• What is exploratory testing? Learning, test design and execution done at the same time, guided by a charter rather than a script.

The four combinations

Why they diverge: severity is about the software, priority about the business. A crash in an obscure corner hurts less than a typo every visitor sees on launch day.

Follow-ups

• Can priority change while severity stays the same? Yes. A minor layout bug becomes P1 when a big client's demo is tomorrow.
• What makes a defect a blocker? It stops testing or a core business flow entirely, with no workaround, such as a build where login always fails.

New ──▶ Assigned ──▶ Open ──▶ Fixed ──▶ Retest ──┬──▶ Verified ──▶ Closed
 │         │                                     │
 │         │                                     └──▶ Reopened ──▶ Assigned (again)
 │         ├──▶ Rejected       (not a bug, or works as designed)
 │         ├──▶ Duplicate      (already reported)
 │         └──▶ Deferred       (fix in a later release)
 └──▶ Needs more info / Cannot reproduce

Tools differ: Jira's simplest workflow is just To Do, In Progress and Done, and every team customises it. In an interview, explain the flow and the decision points rather than reciting one fixed list.

Follow-ups

• Rejected vs deferred? Rejected means it isn't a defect; deferred means it is, but it won't be fixed in this release.
• A closed bug appears again in a later release. Reopen it or log a new one? Teams differ; many log a new bug linked to the old one, so release history stays accurate.

Step by step

1. Recheck. Is it really against the requirement, or against my assumption? Is my build, data or environment unusual?
2. Gather evidence. Steps, test data, build number, screenshots or a video, logs, and the exact requirement or design it contradicts.
3. Understand their view. "Not a bug" often means one of the reasons below.
4. Discuss, don't argue. Keep it about the product and its users, not about who's right.
5. Escalate to the owner of the requirement if you still disagree: the product owner or BA decides what the product should do.
6. Record the decision in the ticket: fixed, rejected as working as designed, or converted into an enhancement.

A comment that keeps things calm and specific

Hi Ravi, on build 2.4.1 (staging, Chrome on Windows 11), applying SAVE10 to a ₹1,200
cart leaves the total at ₹1,200. Story SHOP-88, acceptance criterion 2, says carts
above ₹1,000 get 10% off. Recording and console log attached. Could you take a look,
or let me know if the rule has changed?

Follow-ups

• What if the developer is right? Thank them, close or reject the ticket, and fix your test case or understanding. Being right isn't the goal; the product is.
• What if it keeps happening with one developer? Agree on acceptance criteria before development starts, so disagreements are settled in refinement instead of in tickets.

Title:          Checkout: "Apply coupon" does nothing for a valid code (SAVE10)
ID:             SHOP-231
Environment:    Staging, build 2.4.1; Chrome on Windows 11; also on Android 14 app
Preconditions:  Logged in as [email protected]; cart total ₹1,200 (2 items)

Steps to reproduce:
  1. Open the cart and click "Checkout".
  2. In "Coupon code", type SAVE10.
  3. Click "Apply coupon".

Expected:       The total changes to ₹1,080 and "Coupon applied" appears.
Actual:         Nothing happens: no message, the total stays ₹1,200,
                and no network request is sent (DevTools, Network tab).
Console error:  Uncaught TypeError: Cannot read properties of null (reading 'value')
                    at applyCoupon (coupon.js:42)
Frequency:      5 out of 5 attempts
Severity:       Major (customers can't use any coupon; checkout itself works)
Priority:       High (the festive sale starts on Friday)
Attachments:    apply-coupon.mp4, console.png
Notes:          Works on build 2.4.0. Fails with every code tried (SAVE10, WELCOME50).

Why each part is there

Isolate before you report: try another coupon, another browser and the previous build, and open the browser's DevTools. "No request sent" points to the front end; a request that returns a 500 error points to the server. Those two lines in the report send it to the right developer immediately.

Follow-ups

• What makes a bug title bad? Vague words like "Coupon not working" or "Checkout issue": they don't say where, what or under which conditions.
• Should one report hold several bugs? No. Each defect gets its own report, so each can be assigned, fixed and verified separately.

Differences that commonly hide a bug

Evidence to attach

• A screen recording from a fresh session, showing the steps from the start.
• The browser console log and a HAR file of network traffic (DevTools, Network tab, export). HAR files contain cookies and tokens, so remove them or share the file privately.
• The exact time of the failure and any request IDs, so the developer can find the matching server logs.
• For mobile apps, device logs, such as adb logcat on Android.

If neither of you can reproduce it: record every attempt and condition in the ticket, mark it Cannot reproduce (or Needs more info), and keep watching. Intermittent bugs often reappear under load or in production, and the earlier notes make them much faster to fix then.

Follow-ups

• What does "intermittent" tell you? That the cause depends on something variable: timing, data, concurrency or the environment. Note the frequency, such as "3 out of 10 attempts".
• Should you close the ticket? Not without agreement. A bug that can't be reproduced today isn't proof that it's fixed.

1. Contain

• Reproduce it on a production-like environment; note the affected users, platforms and data.
• Help judge severity, so the team can decide on a hotfix, rollback or feature flag.
• Test the hotfix quickly but properly: retest the bug and run a focused regression around it.

2. Find the root cause, without blame

The five whys, on a real-looking case

Customers were charged twice for one order.
1. Why?  The app retried the payment after a timeout and created a second charge.
2. Why wasn't it caught?  No test covered payment-gateway timeouts.
3. Why not?  The bank's sandbox in staging never times out.
4. Why?  We had no way to simulate a slow gateway.
5. Action: a mock gateway with configurable delays, and a regression test for timeouts.

3. Prevent a repeat: add the scenario to the regression suite, update the RTM, share the lessons with the team, and track defect leakage: the share of defects found after release, such as 3 of 60, or 5%.

In the interview, own it. "I'd acknowledge we missed it and focus on fixing the gap" sounds far stronger than explaining why it wasn't your fault.

Follow-ups

• Is a production bug always the tester's fault? No. Quality is the team's responsibility; the useful question is which part of the process let it through.
• What is defect leakage? Defects found after release divided by all defects found, as a percentage; lower is better.

Your test (Java + TestNG)
   │   driver.findElement(By.id("email"))
   ▼
Selenium client library (Java bindings)
   │   HTTP + JSON, W3C WebDriver protocol
   ▼
Browser driver (chromedriver, geckodriver, msedgedriver, safaridriver)
   │   native automation
   ▼
Browser (Chrome, Firefox, Edge, Safari)

A first test

import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;

public class FirstTest {
    public static void main(String[] args) {
        WebDriver driver = new ChromeDriver();        // Selenium Manager finds or downloads chromedriver
        try {
            driver.get("https://example.com/");
            System.out.println(driver.getTitle());                                 // Example Domain
            System.out.println(driver.findElement(By.tagName("h1")).getText());    // Example Domain
        } finally {
            driver.quit();                            // ends the session and closes the browser
        }
    }
}

What travels over the wire for findElement(By.id("email"))

POST /session/{session id}/element
{"using": "css selector", "value": "#email"}

Response:
{"value": {"element-6066-11e4-a52e-4f735466cecf": "f.8C2A…d.3"}}

The W3C protocol defines five locator strategies: CSS selector, XPath, link text, partial link text and tag name. Selenium's Java client sends By.id and By.name as CSS selectors.

What changed in Selenium 4: the client speaks the W3C WebDriver standard instead of the older JSON Wire Protocol, and Selenium Manager (from 4.6) downloads the right driver automatically. Old tutorials that start with System.setProperty("webdriver.chrome.driver", "C:\\drivers\\chromedriver.exe") are no longer needed.

Follow-ups

• What can't Selenium test? Desktop apps, CAPTCHAs (by design), image content and native mobile apps on its own; Appium covers mobile using the same WebDriver protocol.
• Does Selenium produce reports? No. Reports come from the test framework, such as TestNG, or a tool like Allure.

The page used in the examples

<div class="page">
  <form id="login-form">
    <input id="email" name="email" type="email" data-testid="login-email">
    <input id="password" name="password" type="password">
    <button type="submit" class="btn btn-primary">Log in</button>
    <a href="/forgot">Forgot password?</a>
  </form>
</div>

Absolute vs relative XPath

findElement vs findElements

WebElement email = driver.findElement(By.id("email"));      // the first match, or NoSuchElementException
List<WebElement> errors = driver.findElements(By.cssSelector(".error"));   // all matches; empty if none
boolean hasErrors = !errors.isEmpty();                      // a safe way to check something is absent

In Python, the old find_element_by_id("email") style was removed in Selenium 4.3. Use driver.find_element(By.ID, "email"), even though many tutorials still show the old form.

Follow-ups

• How do you check a locator before using it? In Chrome DevTools, press Ctrl+F in the Elements panel and type the CSS selector or XPath; it highlights the matches and shows how many there are.
• What if the only unique thing is generated, like id="input-4821"? Ask developers to add a data-testid attribute, or anchor on a stable neighbour, such as the field's label text.

<table id="users">
  <thead>
    <tr><th>Name</th><th>Email</th><th>Actions</th></tr>
  </thead>
  <tbody>
    <tr data-email="[email protected]">
      <td>Asha Rao</td>
      <td>[email protected]</td>
      <td><button class="edit">Edit</button> <button class="delete">Delete</button></td>
    </tr>
    <tr data-email="[email protected]">
      <td>Ravi Kumar</td>
      <td>[email protected]</td>
      <td><button class="edit">Edit</button> <button class="delete">Delete</button></td>
    </tr>
  </tbody>
</table>

Four XPaths that find Ravi's Delete button, and only that one

In a test

static WebElement deleteButtonFor(WebDriver driver, String email) {
    return driver.findElement(By.xpath(
            "//tr[td[normalize-space()='" + email + "']]//button[normalize-space()='Delete']"));
}

// deleteButtonFor(driver, "[email protected]").click();

normalize-space() trims and collapses whitespace, so <td> [email protected] </td> still matches. It also matches text inside child elements, such as <button><span>Delete</span></button>, which text() doesn't.

The XPath axes worth knowing

When CSS works: if the row carries the email as an attribute, CSS is simpler: tr[data-email='[email protected]'] button.delete. If the attribute sits on a cell instead, modern browsers' :has() selects the row through it: tr:has(> td[data-email='[email protected]']) button.delete. Either way, CSS matches attributes, never text; jQuery's :contains() isn't real CSS, and browsers reject it as an invalid selector.

Follow-ups

• What if the email contains an apostrophe, like o'[email protected]? A single-quoted XPath string breaks; wrap it in double quotes instead: //td[text()="o'[email protected]"].
• Is XPath slower than CSS? Slightly, in some browsers, but the difference is rarely noticeable; choose the locator that's clearer and more stable.

import java.time.Duration;
import org.openqa.selenium.By;
import org.openqa.selenium.NoSuchElementException;      // Selenium's, not java.util's
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.support.ui.ExpectedConditions;
import org.openqa.selenium.support.ui.FluentWait;
import org.openqa.selenium.support.ui.Wait;
import org.openqa.selenium.support.ui.WebDriverWait;

public class Waits {
    static void implicitWait(WebDriver driver) {
        driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10));   // applies to every findElement
    }

    static void explicitWait(WebDriver driver) {
        WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
        WebElement pay = wait.until(ExpectedConditions.elementToBeClickable(By.id("pay-now")));
        pay.click();
        wait.until(ExpectedConditions.textToBePresentInElementLocated(By.id("status"), "Payment successful"));
    }

    static WebElement fluentWait(WebDriver driver) {
        Wait<WebDriver> wait = new FluentWait<>(driver)
                .withTimeout(Duration.ofSeconds(30))
                .pollingEvery(Duration.ofMillis(500))
                .ignoring(NoSuchElementException.class);
        return wait.until(d -> d.findElement(By.id("receipt")));             // retries until found or 30 s pass
    }
}

Don't mix implicit and explicit waits. Selenium's documentation warns that combining them causes unpredictable wait times; for example, an implicit wait of 10 seconds with an explicit wait of 15 seconds could time out after 20 seconds. Most teams set the implicit wait to zero (the default) and use explicit waits everywhere.

Selenium 4 takes a Duration. The older forms, implicitlyWait(10, TimeUnit.SECONDS) and new WebDriverWait(driver, 10), are deprecated; use the Duration versions.

Follow-ups

• What's the difference between presenceOfElementLocated and visibilityOfElementLocated? Presence means the element is in the page's HTML; visibility means it's also displayed with a size greater than zero. You usually want visibility, or clickability, before interacting.
• Why import Selenium's NoSuchElementException? java.util has one with the same name; ignoring the wrong one means the fluent wait never catches Selenium's exception.

<select id="city" name="city">
  <option value="">Select a city</option>
  <option value="PNQ">Pune</option>
  <option value="BLR">Bengaluru</option>
  <option value="DEL">Delhi</option>
</select>

import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.support.ui.Select;
import org.testng.Assert;

public class CityDropdown {
    static void chooseCity(WebDriver driver) {
        Select city = new Select(driver.findElement(By.id("city")));

        city.selectByVisibleText("Pune");                                   // the text the user sees
        Assert.assertEquals(city.getFirstSelectedOption().getText(), "Pune");

        city.selectByValue("BLR");                                          // the value attribute
        Assert.assertEquals(city.getFirstSelectedOption().getText(), "Bengaluru");

        city.selectByIndex(3);                                              // position, from 0: Delhi (fragile)
        Assert.assertEquals(city.getOptions().size(), 4);                   // includes the placeholder
    }
}

Custom dropdowns (common in React and Angular apps) aren't <select> elements, so new Select(...) throws UnexpectedTagNameException. Click your way through instead:

driver.findElement(By.cssSelector("[data-testid='city-picker']")).click();      // open the list
new WebDriverWait(driver, Duration.ofSeconds(5))
        .until(ExpectedConditions.elementToBeClickable(
                By.xpath("//li[@role='option' and normalize-space()='Pune']")))
        .click();

Follow-ups

• Why is selectByIndex fragile? Adding or reordering one option silently selects a different city. Visible text or value states your intent.
• How would you check the options are in alphabetical order? Read getOptions(), collect their texts, skip the placeholder, and compare with a sorted copy.

import java.time.Duration;
import org.openqa.selenium.Alert;
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.support.ui.ExpectedConditions;
import org.openqa.selenium.support.ui.WebDriverWait;

public class SwitchingContexts {
    static void handleAlert(WebDriver driver) {
        driver.findElement(By.id("delete-account")).click();
        WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(5));
        Alert alert = wait.until(ExpectedConditions.alertIsPresent());
        System.out.println(alert.getText());           // Are you sure?
        alert.accept();                                // OK; alert.dismiss() would press Cancel
    }

    static void handleIframe(WebDriver driver) {
        driver.switchTo().frame("payment-frame");      // by name or id; also by index or WebElement
        driver.findElement(By.id("card-number")).sendKeys("4111111111111111");
        driver.switchTo().defaultContent();            // back to the main page
    }

    static void handleNewTab(WebDriver driver) {
        String original = driver.getWindowHandle();
        driver.findElement(By.linkText("Terms and conditions")).click();      // opens a new tab
        new WebDriverWait(driver, Duration.ofSeconds(5))
                .until(ExpectedConditions.numberOfWindowsToBe(2));
        for (String handle : driver.getWindowHandles()) {
            if (!handle.equals(original)) {
                driver.switchTo().window(handle);
                break;
            }
        }
        System.out.println(driver.getTitle());          // the new tab's title
        driver.close();                                 // closes this tab only
        driver.switchTo().window(original);             // switch back explicitly
    }
}

close() vs quit()

Selenium 4 can open tabs itself: driver.switchTo().newWindow(WindowType.TAB) opens a blank tab and switches to it.

Follow-ups

• How do you type into a prompt() dialog? alert.sendKeys("Asha"), then alert.accept().
• Can Selenium handle the browser's own file-download or print dialogs? No: they aren't part of the page. Set browser preferences, such as a download folder, through ChromeOptions instead.

import org.testng.annotations.*;

public class OrderDemo {
    @BeforeSuite  public void beforeSuite()  { System.out.println("BeforeSuite"); }
    @BeforeTest   public void beforeTest()   { System.out.println("BeforeTest"); }
    @BeforeClass  public void beforeClass()  { System.out.println("BeforeClass"); }
    @BeforeMethod public void beforeMethod() { System.out.println("  BeforeMethod"); }

    @Test(priority = 1) public void login()  { System.out.println("    Test: login"); }
    @Test(priority = 2) public void search() { System.out.println("    Test: search"); }

    @AfterMethod  public void afterMethod()  { System.out.println("  AfterMethod"); }
    @AfterClass   public void afterClass()   { System.out.println("AfterClass"); }
    @AfterTest    public void afterTest()    { System.out.println("AfterTest"); }
    @AfterSuite   public void afterSuite()   { System.out.println("AfterSuite"); }
}

BeforeSuite
BeforeTest
BeforeClass
  BeforeMethod
    Test: login
  AfterMethod
  BeforeMethod
    Test: search
  AfterMethod
AfterClass
AfterTest
AfterSuite

The classic confusion: @BeforeTest doesn't run before each test method; that's @BeforeMethod. A "test" in TestNG is the <test> tag in testng.xml, which can hold many classes.

If you're asked about pytest: it has no annotation hierarchy. Setup and teardown live in fixtures with a scope, such as function, class, module or session, so don't map TestNG's annotations onto it one to one.

Follow-ups

• What is testng.xml for? It defines the suite: which classes, groups and parameters to run, and whether to run them in parallel (question 40 shows one).
• Does a failing @BeforeMethod fail the test? The configuration method fails, and the tests it guards are skipped, which shows up in the report as skips, not failures.

src/test/java/
├── pages/
│   ├── LoginPage.java
│   └── DashboardPage.java
└── tests/
    └── LoginTest.java

// src/test/java/pages/LoginPage.java
package pages;

import java.time.Duration;
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.support.ui.ExpectedConditions;
import org.openqa.selenium.support.ui.WebDriverWait;

public class LoginPage {
    private final WebDriver driver;
    private final WebDriverWait wait;

    private final By email = By.id("email");                              // locators live here, once
    private final By password = By.id("password");
    private final By loginButton = By.cssSelector("button[type='submit']");
    private final By error = By.cssSelector("[role='alert']");

    public LoginPage(WebDriver driver) {
        this.driver = driver;
        this.wait = new WebDriverWait(driver, Duration.ofSeconds(10));
    }

    public LoginPage open(String baseUrl) {
        driver.get(baseUrl + "/login");
        wait.until(ExpectedConditions.visibilityOfElementLocated(email));   // the page has loaded
        return this;
    }

    public DashboardPage loginAs(String user, String pass) {
        submit(user, pass);
        return new DashboardPage(driver);                                  // success leads to the next page
    }

    public LoginPage loginExpectingError(String user, String pass) {
        submit(user, pass);
        return this;                                                       // failure stays on this page
    }

    public String errorText() {
        return wait.until(ExpectedConditions.visibilityOfElementLocated(error)).getText();
    }

    private void submit(String user, String pass) {
        type(email, user);
        type(password, pass);
        driver.findElement(loginButton).click();
    }

    private void type(By locator, String text) {
        WebElement field = wait.until(ExpectedConditions.visibilityOfElementLocated(locator));
        field.clear();
        field.sendKeys(text);
    }
}

// src/test/java/pages/DashboardPage.java
package pages;

import java.time.Duration;
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.support.ui.ExpectedConditions;
import org.openqa.selenium.support.ui.WebDriverWait;

public class DashboardPage {
    private final WebDriverWait wait;
    private final By welcome = By.cssSelector("[data-testid='welcome']");

    public DashboardPage(WebDriver driver) {
        this.wait = new WebDriverWait(driver, Duration.ofSeconds(10));
    }

    public String welcomeText() {
        return wait.until(ExpectedConditions.visibilityOfElementLocated(welcome)).getText();
    }
}

// src/test/java/tests/LoginTest.java
package tests;

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.chrome.ChromeOptions;
import org.testng.Assert;
import org.testng.annotations.AfterMethod;
import org.testng.annotations.BeforeMethod;
import org.testng.annotations.Test;
import pages.DashboardPage;
import pages.LoginPage;

public class LoginTest {
    private static final String BASE_URL = System.getProperty("baseUrl", "https://staging.example.com");
    private WebDriver driver;

    @BeforeMethod
    public void startBrowser() {
        ChromeOptions options = new ChromeOptions();
        if (Boolean.getBoolean("headless")) {                    // mvn test -Dheadless=true
            options.addArguments("--headless=new", "--window-size=1920,1080");
        }
        driver = new ChromeDriver(options);
    }

    @Test
    public void validUserSeesDashboard() {
        DashboardPage dashboard = new LoginPage(driver)
                .open(BASE_URL)
                .loginAs("[email protected]", "Secret@123");
        Assert.assertEquals(dashboard.welcomeText(), "Welcome, Asha");
    }

    @Test
    public void wrongPasswordShowsError() {
        LoginPage page = new LoginPage(driver)
                .open(BASE_URL)
                .loginExpectingError("[email protected]", "wrong-pass");
        Assert.assertEquals(page.errorText(), "Invalid email or password");
    }

    @AfterMethod(alwaysRun = true)
    public void closeBrowser() {
        if (driver != null) {
            driver.quit();
        }
    }
}

Why teams use it

Assertions belong in tests. Selenium's own guidance is that page objects shouldn't make assertions; the one check they may make is that their page has loaded, as open() does here.

PageFactory is an older style you'll see in many frameworks: @FindBy(id = "email") private WebElement email; plus PageFactory.initElements(driver, this) in the constructor. It follows the same pattern with different syntax.

Follow-ups

• What is POM, and why use it? This is the spoken version freshers usually get: one class per page holding its locators and actions, so tests are readable and UI changes are fixed in one place.
• Should a page object return void from actions? Returning the next page object makes navigation explicit and lets tests chain calls, as above.

import org.testng.Assert;
import org.testng.annotations.Test;
import org.testng.asserts.SoftAssert;

public class ProfileTest {
    // Stand-ins for values read from the profile page
    private final String name = "Asha Rao";
    private final String city = "Mumbai";            // wrong: should be Pune
    private final boolean avatarShown = false;       // wrong: should be shown

    @Test
    public void hardAsserts() {
        Assert.assertEquals(name, "Asha Rao");
        Assert.assertEquals(city, "Pune");           // fails here and stops the test
        Assert.assertTrue(avatarShown, "avatar missing");   // never runs
    }

    @Test
    public void softAsserts() {
        SoftAssert soft = new SoftAssert();          // a new one in every test
        soft.assertEquals(name, "Asha Rao");
        soft.assertEquals(city, "Pune");             // recorded; carries on
        soft.assertTrue(avatarShown, "avatar missing");     // recorded; carries on
        soft.assertAll();                            // fails now, listing both problems
    }
}

hardAsserts reports one failure, the city; you only discover the missing avatar after fixing it and running again. softAsserts reports both in one run.

Two easy mistakes

• Argument order: TestNG's assertEquals takes (actual, expected), the reverse of JUnit's (expected, actual). Swap them, and the failure message reads backwards.
• Sharing one SoftAssert across tests as a field: failures from one test leak into the next. Create one per test.

In older Selenium terms, this was "assert vs verify": an assert stops the test, a verify notes the failure and continues. pytest has no built-in soft assert: a failing assert ends the test, so soft checks need a plugin such as pytest-check.

Follow-ups

• Can you mix them in one test? Yes, and it's common: hard-assert that login worked, then soft-assert the page's details.
• What does the failure message contain? The expected and actual values for each failure, plus any message you passed, such as "avatar missing".

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.testng.Assert;
import org.testng.annotations.AfterMethod;
import org.testng.annotations.BeforeMethod;
import org.testng.annotations.DataProvider;
import org.testng.annotations.Test;
import pages.LoginPage;

public class LoginDataTest {
    private WebDriver driver;

    @BeforeMethod
    public void startBrowser() {
        driver = new ChromeDriver();
    }

    @DataProvider(name = "logins")
    public Object[][] logins() {
        return new Object[][] {
            {"[email protected]", "Secret@123", true},        // valid
            {"[email protected]", "wrong-pass", false},       // wrong password
            {"[email protected]", "Secret@123", false},     // unregistered email
            {"", "Secret@123", false},                       // blank email
        };
    }

    @Test(dataProvider = "logins")
    public void login(String email, String password, boolean shouldSucceed) {
        LoginPage page = new LoginPage(driver).open("https://staging.example.com");
        if (shouldSucceed) {
            Assert.assertEquals(page.loginAs(email, password).welcomeText(), "Welcome, Asha");
        } else {
            Assert.assertFalse(page.loginExpectingError(email, password).errorText().isEmpty());
        }
    }

    @AfterMethod(alwaysRun = true)
    public void closeBrowser() {
        driver.quit();
    }
}

The report shows four results for login, each with its parameters, so a failure points straight at the row that broke. LoginPage is the page object from question 32.

Reading the rows from a CSV file instead

email,password,shouldSucceed
[email protected],Secret@123,true
[email protected],wrong-pass,false
,Secret@123,false

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;
import java.util.List;
import org.testng.annotations.DataProvider;

public class LoginCsvData {
    @DataProvider(name = "loginsFromCsv")
    public static Object[][] loginsFromCsv() throws IOException {
        List<String> lines = Files.readAllLines(Path.of("src/test/resources/logins.csv"));
        return lines.stream()
                .skip(1)                                        // the header row
                .map(line -> line.split(",", -1))              // -1 keeps empty trailing fields
                .map(cols -> new Object[] {cols[0], cols[1], Boolean.parseBoolean(cols[2])})
                .toArray(Object[][]::new);
    }
}

A test in another class uses it with @Test(dataProvider = "loginsFromCsv", dataProviderClass = LoginCsvData.class); a provider in another class must be static, or its class must have a no-argument constructor.

Follow-ups

• DataProvider vs @Parameters? @Parameters passes single values from testng.xml, such as the browser name, once per run; a DataProvider supplies many rows, running the test once per row.
• Where should passwords for real test accounts live? Not in the code or the CSV in Git: read them from environment variables or the CI system's secret store.

A quick payback estimate

Manual regression:      16 hours every sprint
Automated regression:   1 hour to run and review + 3 hours of maintenance = 4 hours
Saving per sprint:      12 hours
Cost to build:          120 hours
Break-even:             120 / 12 = 10 sprints (about 5 months of two-week sprints)

After that, every run is time saved, and the suite can run every night, which manual testing never could.

The test pyramid guides where to automate: many fast unit tests at the base, fewer API tests in the middle, and only a thin layer of slow, brittle UI tests at the top. Automating everything through the UI makes suites slow and flaky.

          /\
         /UI\          few: slow, brittle, end to end
        /----\
       / API  \        more: fast, stable
      /--------\
     /  Unit    \      most: fastest, written by developers
    /------------\

Follow-ups

• Can everything be automated? No. Exploratory testing, usability judgements and checks needing human perception stay manual, and some automation costs more to maintain than it saves.
• When would you automate a new feature? Once its behaviour and UI have settled, usually a sprint or two after it ships; automating a moving target wastes effort.

The most common fix: replace a fixed sleep with a wait for the real condition

// Before: flaky. Two seconds is sometimes too short, and always wasted when the page is fast
driver.findElement(By.id("apply-coupon")).click();
Thread.sleep(2000);
Assert.assertEquals(driver.findElement(By.id("total")).getText(), "₹1,080");

// After: waits exactly as long as needed, up to 10 seconds
driver.findElement(By.id("apply-coupon")).click();
new WebDriverWait(driver, Duration.ofSeconds(10))
        .until(ExpectedConditions.textToBePresentInElementLocated(By.id("total"), "₹1,080"));

Reproducing it

• Run the test many times in a row, for example by temporarily adding invocationCount = 50 to its @Test.
• Compare: alone vs in the suite, headed vs headless, serial vs parallel, local vs CI.
• Capture a screenshot and the page source on failure, with a TestNG listener, so every failed nightly run leaves evidence.

Retries are a stopgap. TestNG's IRetryAnalyzer can rerun failed tests, but a test that passes on the second attempt still hides a problem, and sometimes that problem is a real race condition in the app. If you add retries, track which tests needed them and fix those.

Follow-ups

• What's a quarantine? Moving a known-flaky test out of the main suite into a separate run, with a ticket to fix it, so it stops blocking everyone while it's investigated.
• Can a flaky test reveal a real bug? Yes. Timing-dependent failures sometimes come from the app itself, such as a double click creating two orders.

A valid request: POST /api/orders places an order

Invalid requests: the negative tests

Error responses deserve testing too. They shouldn't contain stack traces, SQL errors or server file paths: those help attackers and confuse users.

Checking the schema automatically, in Postman

const schema = {
    type: "object",
    required: ["id", "status", "total", "items"],
    properties: {
        id: { type: "integer" },
        status: { type: "string", enum: ["PLACED", "PAID", "SHIPPED"] },
        total: { type: "number", minimum: 0 },
        items: { type: "array", minItems: 1 }
    }
};

pm.test("matches the order schema", () => {
    pm.response.to.have.jsonSchema(schema);
});

What the status codes themselves mean is covered in the Backend kit, question 3; this question is about what a tester checks.

Follow-ups

• Positive vs negative API tests? Positive tests send valid requests and check the right result; negative tests send invalid, unauthorised or malformed ones and check the API refuses them safely and clearly.
• Why test APIs when the UI is tested? API tests are faster and more stable, they reach cases the UI blocks (such as a negative quantity), and they find defects before the UI exists.

Request 1: POST {{baseUrl}}/api/login, body {"email": "[email protected]", "password": "{{password}}"}. Its post-response script:

pm.test("login returns 200", function () {
    pm.response.to.have.status(200);
});

const body = pm.response.json();

pm.test("response contains a token", function () {
    pm.expect(body.token).to.be.a("string").and.not.empty;
});

pm.environment.set("token", body.token);         // saved for the requests that follow

Request 2: GET {{baseUrl}}/api/me, with the header Authorization: Bearer {{token}} (or the Authorization tab, type Bearer Token, value {{token}}). Its post-response script:

pm.test("status is 200", () => {
    pm.response.to.have.status(200);
});

pm.test("returns Asha's profile", () => {
    const user = pm.response.json();
    pm.expect(user.email).to.eql("[email protected]");
    pm.expect(user).to.have.property("id");
});

pm.test("responds in under 500 ms", () => {
    pm.expect(pm.response.responseTime).to.be.below(500);
});

pm.test("returns JSON", () => {
    pm.expect(pm.response.headers.get("Content-Type")).to.include("application/json");
});

Request 3, the negative case: GET {{baseUrl}}/api/me with no Authorization header

pm.test("rejects a request without a token", () => {
    pm.response.to.have.status(401);
});

Collections and environments: a collection is a saved, ordered set of requests with their scripts; an environment is a set of variables, such as baseUrl and password, so the same collection runs against dev, staging or production by switching environments.

When two scopes define the same name, the narrowest wins: local, then data, then environment, then collection, then global.

Running it from the command line, as CI does:

newman run shop-api.postman_collection.json -e staging.postman_environment.json

→ Login
  POST http://localhost:3000/api/login [200 OK, …]
  ✓  login returns 200
  ✓  response contains a token

→ Profile
  GET http://localhost:3000/api/me [200 OK, …]
  ✓  status is 200
  ✓  returns Asha's profile
  ✓  responds in under 500 ms
  ✓  returns JSON

→ Profile without a token
  GET http://localhost:3000/api/me [401 Unauthorized, …]
  ✓  rejects a request without a token

That's Newman's output from running this collection against a local test API, trimmed. Newman exits with an error code if any test fails, which is what fails a CI build.

Old tutorials use tests["Status code is 200"] = responseCode.code === 200;. That syntax is deprecated; write pm.test with pm.expect or pm.response.to.

Follow-ups

• Environment variable vs collection variable for the token? The environment, because the token belongs to the server and user you're testing against; switching to another environment shouldn't reuse it.
• How would you run the login with many users? Put the users in a CSV file, refer to them as {{email}} and {{password}}, and pass the file to the Collection Runner or newman run … -d users.csv.

One shopping site, preparing for a Diwali sale that expects 5,000 users at once

What to measure

Percentiles matter more than averages: an average of 800 ms can hide the 5% of users waiting 6 seconds.

Common tools: JMeter, k6, Gatling and Locust. Whatever the tool, the test environment should be as close to production as possible, or the numbers mean little.

Follow-ups

• What's a performance bottleneck? The one resource that limits the whole system, such as a slow database query or too few connections in a pool. Tests find the symptom; profiling and monitoring find the bottleneck.
• Who sets the targets? The business and the team together, from expected traffic; testers should ask for numbers ("how many users, how fast?") before testing, not after.

The suite file and the Maven setup

<!DOCTYPE suite SYSTEM "https://testng.org/testng-1.0.dtd">
<suite name="Regression" parallel="classes" thread-count="3">
  <test name="Web regression">
    <groups>
      <run>
        <include name="smoke"/>
        <include name="regression"/>
      </run>
    </groups>
    <classes>
      <class name="tests.LoginTest"/>
      <class name="tests.CheckoutTest"/>
    </classes>
  </test>
</suite>

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-surefire-plugin</artifactId>
  <version>3.5.2</version>
  <configuration>
    <suiteXmlFiles>
      <suiteXmlFile>testng.xml</suiteXmlFile>
    </suiteXmlFiles>
  </configuration>
</plugin>

GitHub Actions: .github/workflows/ui-tests.yml

name: UI tests

on:
  push:
    branches: [main]
  pull_request:
  schedule:
    - cron: "30 20 * * *"   # 2:00 a.m. IST every night (GitHub's cron runs in UTC)

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: "17"
          cache: maven
      - name: Run the TestNG suite headless
        run: mvn -B test -Dheadless=true -DbaseUrl=https://staging.example.com
      - name: Upload test reports
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: test-reports
          path: target/surefire-reports/

-Dheadless=true reaches the test as a system property, which is what LoginTest in question 32 checks before adding --headless=new. GitHub's Ubuntu runners come with Chrome installed, and Selenium Manager fetches the matching driver.

The same in Jenkins: a declarative Jenkinsfile

pipeline {
    agent any
    triggers { cron('H 2 * * *') }               // nightly, some time in the 2 a.m. hour
    stages {
        stage('Test') {
            steps {
                sh 'mvn -B test -Dheadless=true'
            }
        }
    }
    post {
        always {
            junit 'target/surefire-reports/*.xml'                          // test results page and trend
            archiveArtifacts artifacts: 'target/surefire-reports/**', allowEmptyArchive: true
        }
    }
}

How a failure stops the pipeline: when a test fails, Surefire reports BUILD FAILURE and Maven exits with a non-zero code; GitHub Actions and Jenkins treat that as a failed step. (Passing -Dmaven.test.failure.ignore=true lets Jenkins mark the build unstable instead, so later steps still run.)

CI/CD in general, building and deploying the application, is in the Backend kit, question 40; this question is about the test suite's part in it.

Follow-ups

• How do you make a long suite faster in CI? Run it in parallel: parallel="classes" with a thread-count in testng.xml, Selenium Grid, or splitting it across CI jobs; and run only the smoke group on pull requests.
• Where do test credentials go? In the CI system's secrets (GitHub Actions secrets, Jenkins credentials), passed as environment variables, never in the repository.