Hybrid Framework Interview Kit

What they are checking

Whether your depth matches the role's stack, and whether you rate yourself honestly. A list with ten "expert" tools is a red flag. A short list with clear levels and evidence reads as senior.

Use one definition for each level

Your evidence table (adjust the levels to your real history)

Model answer

What they are checking

That you can reason about why a structure exists, not just follow one. They want layers, trade-offs, and evidence that you maintained the framework after writing it.

The patterns they name, explained

How this framework handles each concern

• Layers: config → BrowserFactory → BaseClass (lifecycle) → BasePage (wait-backed actions) → page objects → tests → listeners → report. Each layer only talks to the one below.
• Test data: Excel through Apache POI. ExcelReader skips the header and uses DataFormatter so a postal code stays 560001 instead of 560001.0. DataProviders maps each sheet to a provider, and getDefaultUser() removes hard-coded credentials.
• Configuration: one properties file loaded once in a static block. Any key can be overridden with -Dkey=value, so CI can switch browser or headless mode without editing files.
• Reporting: a TestNG ITestListener logs every event and, driven by screenshot_on_* flags, saves a PNG and embeds the Base64 image in the ChainTest HTML report.
• Reusability: BasePage wraps click, type, getText and select in explicit waits. A new page is a handful of locators and methods. A ThreadLocal driver makes parallel execution a one-line suite change.
• Maintainability: locators use id and data-test, and every assertion carries a failure message.

Model answer

What they are checking

Whether you test below the UI. Senior roles expect most checks to live at the API layer, because API tests are faster and more stable than UI tests. That's the test pyramid.

Protocols, explained

Techniques, explained

• RestAssured: Java DSL in given() / when() / then() form. Share base URI, headers and auth in a RequestSpecification, and map JSON to POJOs with Jackson.
• Postman / Newman: collections with environment variables and test scripts. newman run executes them from CI with a JUnit or HTML reporter.
• Schema validation: assert that the response shape matches a JSON Schema (required fields, types, formats). This catches a renamed or removed field that a value check might miss.
• Contract testing (Pact): consumer-driven. The consumer's tests record the requests they make and the responses they expect into a pact file, publish it to a Pact Broker, and the provider's build replays it against the real service. A breaking change fails the provider's pipeline before deployment, without an end-to-end environment.
• Database validation: after an API call, query the database with JDBC to confirm the state was persisted correctly (row created, status updated, no duplicates). Clean up or use unique data so runs stay independent.
• OAuth 2.0: for machine-to-machine calls, the client-credentials flow fetches an access token from the token endpoint. Cache it until shortly before expiry and inject it through a filter or spec, so tests never hard-code tokens.
• JWT: a signed token with header, claims and signature. Test expired tokens, tampered signatures, missing scopes and a wrong audience; each should return 401 or 403.
• Mocking and virtualization: WireMock (or MockServer) stubs third-party services such as payment or SMS. You can also inject faults (delays, 500s, malformed bodies) to test retries and timeouts, which you can't do safely against real providers.

What a solid RestAssured test looks like

// Shared settings for every call: base URL, JSON, and a cached OAuth token
RequestSpecification spec = new RequestSpecBuilder()
        .setBaseUri(ConfigReader.getProperty("apiBaseUrl"))
        .setContentType(ContentType.JSON)
        .addHeader("Authorization", "Bearer " + TokenManager.getToken())
        .build();

// Create an order, then validate status, schema and one business rule
String orderId =
    given().spec(spec).body(new OrderRequest("SKU-123", 2))
    .when().post("/orders")
    .then().statusCode(201)
           .body(matchesJsonSchemaInClasspath("schemas/order.json"))
           .body("quantity", equalTo(2))
           .extract().path("id");

// Backend check: the order really exists in the database
Assert.assertEquals(OrderDao.getStatus(orderId), "CREATED",
        "Order was not persisted with status CREATED");

Model answer

What they are checking

Whether your tests actually protect releases: they run automatically, fast enough to give feedback, and a failure stops a bad build.

Suite organisation

In TestNG, tag tests with @Test(groups = {"smoke","regression"}) and create one suite file per level (smoke.xml, regression.xml). This framework already selects the file with -Dsuitefile=smoke.xml.

Parallel, container and cloud execution

• Parallel: parallel="methods" thread-count="4" in the suite. It's safe only because the driver is in a ThreadLocal and every test creates its own data and browser.
• Selenium Grid 4: a hub routes sessions to browser nodes. The framework switches from new ChromeDriver() to new RemoteWebDriver(gridUrl, options), which would be a new branch in BrowserFactory driven by config.
• Docker: the selenium/standalone-chrome image or a docker-compose Grid gives the same browser version on every machine. That removes most "passes on my laptop" failures.
• Cloud (BrowserStack, Sauce Labs, LambdaTest): the same RemoteWebDriver with vendor capabilities (browser, OS, version, build name). A tunnel reaches private test environments. You get many browser and OS combinations plus a video of every session.

Quality gates

• Hard gate: any smoke failure fails the pipeline. Surefire does this by default with a non-zero exit code.
• Branch protection: the smoke job is a required status check, so a pull request can't merge while it's red.
• Release gate: 100% smoke pass, regression pass rate above an agreed threshold with every failure triaged, and no open critical or blocker defects.
• Code-level gates owned with developers: unit-test coverage and static analysis in SonarQube.
• Flaky tests are quarantined into a separate non-blocking job with a ticket and an owner. The gate itself is never loosened.

A pipeline for this framework (GitHub Actions)

name: ui-tests
on: [pull_request, workflow_dispatch]
jobs:
  smoke:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with: { distribution: temurin, java-version: '21', cache: maven }
      # Chrome is preinstalled on the runner; config overrides come from -D
      - run: mvn -B clean test -Dsuitefile=testng.xml -Dheadless=true
      - uses: actions/upload-artifact@v4
        if: always()          # keep the report even when tests fail
        with:
          name: chaintest-report
          path: |
            reports/chaintest/
            screenshots/

Model answer

What they are checking

A systematic diagnosis method, not "we added retries". Seniors classify each failure, fix the cause, and measure whether the fix worked.

Diagnosis method

1. Reproduce: rerun the single test many times, and also run it in parallel, to see whether it fails alone or only under load.
2. Collect evidence: failure screenshot, console log, browser log and video, plus the exact exception and the step where it happened.
3. Classify the cause: timing and waits, test data or shared state, test order, environment or browser, external dependencies, locators, or infrastructure.
4. Fix the cause, not the symptom: retries hide the problem and Thread.sleep makes the suite slow without fixing it.
5. Track it: keep a flake log per test and quarantine the test with a ticket until it's fixed.

Real root causes found while building this framework

Metrics, defined

Model answer

What they are checking

Whether you multiply quality through other people, and whether you can tell a specific, measurable story. Answer the example in STAR form: Situation, Task, Action, Result.

Shift-left practices, explained

• Three Amigos: product, a developer and QA review a story before it's built, and write acceptance criteria in Given / When / Then so everyone agrees what "done" means and the criteria map straight to tests.
• Test pyramid ownership: push checks down. Developers own unit tests, integration and API tests cover business rules, and the UI keeps a thin layer of end-to-end journeys. QA reviews unit and integration coverage for risky areas.
• Testability in design reviews: ask for stable data-test attributes, seedable test data and API hooks before the UI is built.
• Code review for test code, with a checklist: independent tests, no Thread.sleep, no hard-coded data, locators only in page objects, every assertion with a message, and no weakened assertions.
• Definition of Done includes automated tests merged and green in CI.

Mentoring approach you can describe

Use a written guide like this site to explain the framework, pair on the first page object and test, review the first few pull requests closely against the checklist, then hand over ownership of a feature area. Measure it by how soon a new engineer merges an independent test, and by review comments per pull request falling over time.

Model answer (STAR)

What they are checking

Whether coverage decisions are driven by data and risk rather than "test everything everywhere", and whether you understand how mobile automation differs from web.

Mobile concepts, explained

Coverage strategy: a tiered matrix driven by analytics

Review the matrix every quarter against analytics. Cross-browser runs focus on layout, input and JavaScript differences, so a small set of journeys runs on every browser rather than the whole suite.

Real-device clouds

BrowserStack, Sauce Labs, LambdaTest and AWS Device Farm host real phones and browser/OS combinations. The framework connects with RemoteWebDriver or AndroidDriver/IOSDriver pointed at the vendor hub, passing capabilities for device, OS version, app build and build name. A local tunnel reaches staging. You get parallel sessions, videos and device logs, and no device lab to maintain.

Model answer