Top 30 TestNG Interview Questions and Answers (2026)

TL;DR

The top TestNG interview questions cover lifecycle annotations, assertions, DataProviders, parameters, groups, dependencies, parallel execution, listeners, retries, and CI integration. Strong answers also explain isolation, failure evidence, maintainability, and when a TestNG feature should not be used.

Key Takeaways

• Choose the narrowest TestNG lifecycle annotation that matches the resource you create and always provide reliable teardown.
• Use DataProvider for typed test cases, Parameters for suite configuration, and factories when constructor-created test instances are truly required.
• Parallel TestNG execution succeeds only when drivers, data, mutable state, and report artifacts are isolated per invocation.
• Treat dependencies and retries as exceptional controls because both can hide useful coverage or product instability.
• Use listeners for observation and reporting, while transformers are appropriate when annotation behavior must change before execution.
• Keep assertions focused on business outcomes and attach first-failure evidence before cleanup destroys diagnostic state.
• Explain TestNG as an orchestration layer within a test architecture, not as the entire automation framework.

The top TestNG interview questions assess more than annotation recall. Interviewers want to know whether you can design deterministic Java tests, choose the right lifecycle, parameterize cases, isolate parallel work, preserve failure evidence, and integrate a suite into CI without hiding product defects.

This guide uses stable TestNG 7 APIs that remain relevant in 2026. The Java examples are deliberately small and runnable, but the explanations address the framework decisions expected from experienced QA automation engineers and SDETs.

TL;DR

Use TestNG to schedule and observe tests. Keep browser pages, API clients, domain assertions, data builders, and environment configuration in separate layers.

1. Set Up a Runnable TestNG Project

TestNG runs Java methods marked with @Test, discovers configuration methods, applies groups and dependencies, and reports results. It can be launched from an IDE, Maven, Gradle, a suite XML file, or programmatically. In interviews, distinguish TestNG from Selenium: TestNG orchestrates tests, while Selenium WebDriver controls browsers.

This Maven configuration uses TestNG 7.11.0 and Surefire 3.5.2, both real published releases. Newer compatible releases may be available, so production repositories should use their approved dependency policy.

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>example</groupId>
  <artifactId>testng-interview-lab</artifactId>
  <version>1.0.0</version>
  <properties>
    <maven.compiler.release>17</maven.compiler.release>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>
  <dependencies>
    <dependency>
      <groupId>org.testng</groupId>
      <artifactId>testng</artifactId>
      <version>7.11.0</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>3.5.2</version>
      </plugin>
    </plugins>
  </build>
</project>

Run tests with mvn test. A minimal test imports org.testng.Assert and org.testng.annotations.Test, calls production code, and asserts an observable outcome.

2. Choose TestNG Lifecycle Annotations Deliberately

Configuration annotations define scope. @BeforeSuite and @AfterSuite wrap the full suite, @BeforeTest and @AfterTest wrap a <test> element in suite XML, @BeforeClass and @AfterClass wrap a test class, and @BeforeMethod and @AfterMethod run around each test method invocation. Package and group configuration annotations cover specialized scopes.

The word Test is a frequent trap. @BeforeTest does not mean before every @Test method. For a clean browser per test method, @BeforeMethod is normally the relevant scope.

import org.testng.Assert;
import org.testng.annotations.AfterMethod;
import org.testng.annotations.BeforeMethod;
import org.testng.annotations.Test;

public class CartServiceTest {
  private CartService cart;

  @BeforeMethod(alwaysRun = true)
  public void createCart() {
    cart = new CartService();
  }

  @AfterMethod(alwaysRun = true)
  public void releaseCart() {
    cart = null;
  }

  @Test
  public void addingItemChangesTotal() {
    cart.add("keyboard", 49.99);
    Assert.assertEquals(cart.total(), 49.99, 0.001);
  }
}

alwaysRun = true is useful for cleanup and selected configuration paths, but it is not a substitute for idempotent teardown. Teardown should tolerate partial setup because setup itself can fail.

3. Write Assertions That Explain Product Behavior

TestNG supplies equality, truth, null, identity, collection, and exception assertions through Assert. A hard assertion throws immediately. SoftAssert records failures and continues until assertAll() is called. Forgetting assertAll() makes failures invisible, which is why soft assertions need disciplined use.

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

public class PriceRulesTest {
  @Test
  public void rejectsNegativeQuantity() {
    IllegalArgumentException error = Assert.expectThrows(
        IllegalArgumentException.class,
        () -> PriceRules.total(10.00, -1));

    Assert.assertEquals(error.getMessage(), "quantity must be positive");
  }
}

One test can contain several related assertions if they describe one behavior, but a long chain makes the first failure obscure later evidence. Compare domain values with deliberate precision. For money, prefer decimal representations in production rather than relying on a generous floating-point delta.

Assertion messages should add context not already obvious from the expression, such as the order ID or expected state transition. Never log secrets, access tokens, or unnecessary personal data.

4. Parameterize Tests With DataProvider and Parameters

@DataProvider supplies argument rows to a test method. It fits data-driven behavior because each row becomes a distinct invocation. The provider can return Object[][] or an iterator of object arrays. Keep types and case names readable rather than building a huge matrix that is impossible to diagnose.

import org.testng.Assert;
import org.testng.annotations.DataProvider;
import org.testng.annotations.Test;

public class StatusRuleTest {
  @DataProvider(name = "transitions")
  public Object[][] transitions() {
    return new Object[][] {
        {"PENDING", "PAID", true},
        {"PENDING", "CANCELLED", true},
        {"CANCELLED", "PAID", false}
    };
  }

  @Test(dataProvider = "transitions")
  public void validatesTransition(String from, String to, boolean expected) {
    Assert.assertEquals(StatusRules.canMove(from, to), expected,
        "transition " + from + " -> " + to);
  }
}

@Parameters reads values from suite XML, which is useful for browser, environment, or region configuration. @Optional can provide a default, but secrets should come from a secret manager or protected environment variables. A factory creates test class instances, often with constructor data. Use it only when instance-level configuration provides real value because factories add discovery and reporting complexity.

For a broader data strategy, see API test data management patterns.

5. Organize Coverage With Groups and Dependencies

Groups label tests by purpose or capability, such as smoke, regression, contract, or payments. Suite XML and build configuration can include or exclude them. Good group names represent stable test intent. Avoid labels tied to temporary people or arbitrary execution order.

Dependencies express that one TestNG method or group should run only if another succeeds. They can be useful for a true workflow probe, but they create skipped tests and reduce diagnostic independence. Most regression tests should arrange their own prerequisite state rather than depending on another test's side effect.

@Test(groups = "checkout")
public void createOrder() { /* independent arrangement and assertion */ }

@Test(groups = {"checkout", "smoke"})
public void payForOrder() { /* creates its own payable order */ }

TestNG also supports priority, but priority is not a substitute for isolation. If a test requires state from a lower-priority test, the suite is fragile under filtering, parallel execution, and retries. Explain this tradeoff when an interviewer asks how to run tests in order.

6. Make Parallel Execution Safe

TestNG can run methods, classes, tests, or instances in parallel depending on suite settings. Parallelism reduces elapsed time only when the application and test infrastructure have capacity. It also exposes shared mutable state, reused test accounts, colliding files, and static WebDriver bugs.

<!DOCTYPE suite SYSTEM "https://testng.org/testng-1.0.dtd">
<suite name="regression" parallel="methods" thread-count="4">
  <test name="service-tests">
    <packages>
      <package name="example.tests"/>
    </packages>
  </test>
</suite>

Every invocation needs isolated mutable state. For browser tests, create one driver per test invocation and never place a shared driver in a static field. Unique test data, download directories, ports, report paths, and cleanup identifiers are equally important. ThreadLocal can associate a driver with a thread, but it requires remove() and does not repair shared page objects or accounts.

Data providers can declare parallel = true. That is useful for independent cases, but providers and their returned objects must also be safe. Begin with low concurrency, measure, then scale until environment contention or product throttling becomes the limiting factor.

7. Use Listeners, Reporters, and Transformers Correctly

Listeners observe execution events. ITestListener receives test start, success, failure, skip, and related callbacks. IInvokedMethodListener wraps invoked methods, while ISuiteListener observes suites. A reporter works with completed execution data to create a report. An annotation transformer can modify recognized annotation properties before execution.

import org.testng.ITestListener;
import org.testng.ITestResult;

public final class FailureListener implements ITestListener {
  @Override
  public void onTestFailure(ITestResult result) {
    String method = result.getMethod().getQualifiedName();
    Throwable cause = result.getThrowable();
    System.err.println("FAILED: " + method);
    if (cause != null) {
      System.err.println(cause.getClass().getName() + ": " + cause.getMessage());
    }
  }
}

Register the listener with @Listeners(FailureListener.class), suite XML, or the appropriate build integration. Keep listener failures from replacing the original test failure. Capture screenshots, page source, logs, traces, and request IDs only when available, with size limits and redaction.

For reporting architecture and CI publishing, use the Allure reporting in CI guide.

8. Retry Only Classified Transient Failures

IRetryAnalyzer decides whether TestNG should invoke a failed test again. A bounded retry can help with a known transient dependency, but an unconditional retry turns instability into a delayed green build. Record every attempt and preserve the first failure.

import java.util.concurrent.atomic.AtomicInteger;
import org.testng.IRetryAnalyzer;
import org.testng.ITestResult;

public final class OneRetry implements IRetryAnalyzer {
  private final AtomicInteger attempts = new AtomicInteger();

  @Override
  public boolean retry(ITestResult result) {
    return isRetryable(result.getThrowable()) && attempts.getAndIncrement() < 1;
  }

  private boolean isRetryable(Throwable error) {
    return error instanceof java.net.SocketTimeoutException;
  }
}

The analyzer instance lifecycle and parallel behavior deserve attention. Mutable counters must not accidentally share policy across unrelated tests. Teams often apply retry through IAnnotationTransformer, but the transform should be explicit, reviewed, and visible in reports.

Separate an invocation retry from a CI job rerun. A test-level retry retains more context but can repeat side effects. Before retrying a payment, create operation, or message publish, confirm idempotency and cleanup. The Java automation scenario interview guide offers more drills on evidence-first flake diagnosis.

9. Top TestNG Interview Questions for Selenium and API Suites

TestNG can orchestrate browser and API checks in the same repository, but each layer should preserve its own abstractions. A Selenium test should depend on a page or task interface rather than raw locators everywhere. An API test should depend on a typed client and domain assertions rather than embedding request construction into every method.

Use TestNG lifecycle methods to create the correct resource at the correct scope. A browser is often per method for isolation. An immutable API client may be per class or suite if it holds no test-specific mutable state. Authentication tokens may need refresh and must never leak into reports.

Do not use UI setup for every UI test when an approved API can create state more reliably. Conversely, do not bypass the UI when the setup journey itself is the behavior under test. A layered portfolio might contain fast domain tests, service contract tests, a focused API suite, component checks, and a smaller browser journey suite.

For REST Assured syntax and assertion patterns, review given, when, then API testing examples. TestNG schedules those tests, while the API library performs HTTP calls.

10. How to Answer Top TestNG Interview Questions

When answering top TestNG interview questions, define the feature, give one appropriate use, name a risk, and describe how you would verify it in CI. For example: A DataProvider creates separate invocations from argument rows. I use it for compact behavior matrices, keep a readable case identifier, and avoid shared mutable objects when parallel is enabled.

If asked to design a framework, start from responsibilities: test intent, domain workflows, browser pages or API clients, data builders, configuration, lifecycle, assertions, reporting, and CI. TestNG owns discovery and orchestration, not every layer. This prevents the vague claim that TestNG is our framework.

Be precise about scope. @BeforeTest wraps an XML <test>, and @BeforeMethod wraps test method invocations. dependsOnMethods controls skip behavior, while priority influences order but does not create a robust state contract. parallel=methods increases isolation requirements. Exact statements build interviewer trust.

Finally, explain failure policy. Preserve original evidence, distinguish assertion failure from configuration failure, quarantine only with ownership and an exit condition, and fail a release signal for the right reason.

Interview Questions and Answers

The following 30 answers cover TestNG fundamentals and senior framework judgment. Practice each answer with one example from your own automation work.

Q1: What is TestNG?

TestNG is a Java testing framework that provides test discovery, lifecycle configuration, assertions, parameterization, grouping, dependencies, parallel execution, listeners, and reporting hooks. It can orchestrate unit, API, integration, and browser tests. Selenium is separate and controls browsers.

Q2: What are the main TestNG annotations?

@Test marks test methods. Configuration includes before and after annotations at suite, test, class, method, group, and package scope. Choose the narrowest scope matching the resource lifecycle and make teardown safe after partial setup.

Q3: What is the execution order of configuration annotations?

The general outer-to-inner setup order is suite, test, class, and method, with teardown in reverse. Package and group callbacks apply when their scopes are entered. Avoid relying on incidental method declaration order and verify complex suite behavior with a small probe.

Q4: What does @BeforeTest mean?

It runs before the test methods belonging to a <test> element in TestNG suite XML. It does not run before each @Test method. Use @BeforeMethod for per-invocation setup.

Q5: How do hard and soft assertions differ?

A hard assertion throws immediately, so the current method stops unless the failure is caught. SoftAssert records failures so related checks can continue, then throws when assertAll() is called. Missing assertAll() is a serious false-pass risk.

Q6: How do you test an expected exception?

Use Assert.expectThrows when you need to inspect the exception, or the supported expected-exception attributes on @Test for a concise case. Assert meaningful exception details without overfitting an unstable message. Also verify that no prohibited side effect occurred.

Q7: What is a DataProvider?

A method marked @DataProvider supplies argument rows to a test, creating a separate invocation per row. It is suitable for a compact behavior matrix. Keep cases typed, named, independent, and diagnosable.

Q8: DataProvider versus Parameters, what is the difference?

DataProvider supplies test-case data in Java and supports multiple invocations. @Parameters receives suite XML values and fits execution configuration such as browser or region. Environment secrets belong in protected configuration, not XML committed to source.

Q9: What is @Factory?

A factory supplies test class instances, commonly with different constructor data. It is useful when instance-level configuration is central to the design. Prefer DataProvider for ordinary method cases because factories add instance lifecycle and reporting complexity.

Q10: What are TestNG groups?

Groups are labels used to include, exclude, configure, or depend on sets of tests. Stable intent labels such as smoke, contract, and accessibility are useful. A test may belong to several groups.

Q11: How do dependencies work?

dependsOnMethods and dependsOnGroups express prerequisite success. A failed prerequisite normally causes the dependent test to skip. Use dependencies for genuine workflow semantics, not as a general state-sharing mechanism.

Q12: What does alwaysRun do?

Its exact effect depends on whether it is applied to a test or configuration method. It is commonly used to ensure teardown runs despite earlier failures and to control group-related configuration behavior. Cleanup must still tolerate resources that were never fully created.

Q13: How do you disable a TestNG test?

Use @Test(enabled = false), or exclude it through suite or build configuration. A disabled test should have a tracked reason, owner, and exit condition. Silent permanent disablement creates false confidence.

Q14: What are priority and invocationCount?

priority influences execution order among relevant methods, while invocationCount requests repeated invocation. Neither provides safe shared state. Repetition needs independent data and a clear reason, such as a controlled concurrency probe.

Q15: How do you set a test timeout?

TestNG supports a time-out attribute on @Test and suite-level configuration. A timeout bounds test execution but does not identify why the system waited. Preserve thread, browser, network, and application evidence before cleanup.

Q16: How do you run TestNG tests in parallel?

Configure parallel mode and thread count in suite XML or supported build settings, or enable a parallel DataProvider. Isolate drivers, accounts, data, ports, files, and mutable objects. Increase concurrency only after measuring environment capacity.

Q17: Why is a static WebDriver unsafe?

Parallel methods can overwrite or quit the same static driver, so tests act on the wrong session. Create a driver per invocation or use a carefully managed thread association. Page objects and test data must also be isolated.

Q18: What is a TestNG listener?

A listener receives lifecycle callbacks for tests, methods, suites, execution, or other framework events. Use listeners for reporting, telemetry, and bounded artifact capture. Listener code must not hide the original failure.

Q19: What is an annotation transformer?

A transformer changes supported annotation properties before TestNG executes tests. Teams may use one to apply retry or adjust groups centrally. Keep transformations explicit because hidden execution changes make local and CI behavior hard to explain.

Q20: How do you implement retry?

Implement IRetryAnalyzer and return true only within a bounded, classified policy. Attach it explicitly or through a transformer. Record every attempt, retain the first failure, and confirm repeated operations are safe.

Q21: Should every failed test be retried?

No. Assertion defects, deterministic product bugs, bad locators, and invalid data should fail immediately. Retry only understood transient classes while the root cause is being managed, and publish retry rates as quality evidence.

Q22: How do you pass browser or environment values?

Use suite parameters, Maven or Gradle properties, or environment-backed configuration with validation and safe defaults. Do not hardcode secrets or scatter System.getenv calls through tests. Emit a redacted configuration summary at suite start.

Q23: How do you capture a screenshot on failure?

Use an ITestListener failure callback or an after-method that receives ITestResult, then access the current test's driver. Capture before quitting the browser, use a unique artifact path, and tolerate missing sessions. Redact or restrict sensitive pages.

Q24: How do you run only smoke tests?

Assign stable smoke groups and include that group through suite XML or build configuration. Smoke should represent a small, high-signal release or deployment check. Do not make it an arbitrary list of the fastest tests.

Q25: What is testng.xml used for?

It defines suites, tests, classes or packages, groups, parameters, listeners, and execution settings such as parallelism. Keep suite files reviewable and avoid duplicating configuration across many nearly identical files. Build tools can select the suite for CI.

Q26: How does TestNG integrate with Maven?

Maven Surefire commonly discovers and executes TestNG tests during the test phase. It can select suite XML files, groups, properties, and parallel settings. Pin compatible plugin and framework versions and archive both machine-readable and human-readable results.

Q27: How would you design a TestNG automation framework?

Separate orchestration from domain workflows, pages or clients, data, configuration, assertions, artifacts, and CI. Match lifecycle scope to each resource, enforce parallel isolation, and make failure output actionable. Start small and add abstractions only for repeated, stable needs.

Q28: How do you handle flaky TestNG tests?

Preserve first-failure evidence and classify product, test code, data, environment, or infrastructure causes. Reproduce and remove the cause instead of adding blind retries or sleeps. If quarantine is necessary, assign an owner and expiration condition.

Q29: How do you make DataProvider failures readable?

Include a compact case identifier, use typed case objects when argument lists grow, and provide meaningful assertion context. Avoid secrets and enormous object toString() output. Keep each row independent so one failure does not contaminate another.

Q30: TestNG versus JUnit, which should a team choose?

Both are capable Java testing frameworks with different ecosystems and conventions. Compare required features, existing code, IDE and build support, extensions, team expertise, and migration cost. Do not choose from an outdated feature checklist or mix frameworks without a reason.

Common Mistakes

• Saying @BeforeTest runs before every test method.
• Sharing a static WebDriver, mutable client state, or one test account across parallel methods.
• Using priorities and dependencies to build a long stateful regression chain.
• Creating a huge DataProvider whose failing row cannot be identified.
• Using SoftAssert without calling assertAll().
• Retrying every failure and reporting only the final passing attempt.
• Capturing screenshots after teardown has already quit the browser.
• Putting product logic, locators, test data, and reporting inside one test class.
• Treating enabled, excluded, or quarantined tests as solved without ownership.
• Claiming TestNG itself is the complete automation framework.

Conclusion

The top TestNG interview questions reveal whether you can control lifecycle, data, parallelism, and failure behavior in a maintainable Java suite. Accurate annotation definitions are the starting point. The stronger signal is knowing the cost of each feature and selecting it for a clear testing need.

Build the sample project, add a parallel DataProvider and a failure listener, then deliberately create a shared-state defect and diagnose it. That exercise turns framework vocabulary into the practical judgment interviewers expect.

Interview Questions and Answers

Frequently Asked Questions

Related Guides

• TestNG Interview Questions and Answers (2026)
• TestNG Interview Questions and Answers
• Top 30 Agile Interview Questions and Answers (2026)
• Top 30 API testing Interview Questions and Answers (2026)
• Top 30 Appium Interview Questions and Answers (2026)
• Top 30 Automation Testing Interview Questions and Answers (2026)