Track A: AI for Software Testers

AI-generated test cases and scenarios

The most common first use, and the one where the gap between a lazy prompt and a good one is widest.

• Give the model the rules, not just the story: field types, lengths, validation messages, roles, states.
• Ask for coverage by technique – boundary, equivalence class, negative, role-based, state transition – rather than “test cases”.
• Demand the output as JSON against a schema so it imports into your test management tool.
• Review every case. The model invents plausible validations that your application does not have.
• The real value is not the cases it writes – it is the questions it raises about the requirement.

You are a senior test analyst. Below is a requirement and the field rules.

Produce test cases as JSON: {"cases":[{"id","title","technique","steps","expected","type"}]}
- technique must be one of: boundary, equivalence, negative, state, role
- at least 2 boundary cases per numeric or length-limited field
- include every validation message exactly as written below
- do not invent fields, roles or messages that are not listed

REQUIREMENT:
<paste the story>

FIELD RULES:
<paste the table: field, type, required, min, max, message>

Intelligent test data generation

Where AI quietly saves the most hours – realistic, varied, and legally safe data.

• Ask for data that matches your domain: Indian names, real PIN codes, valid GSTIN and IFSC formats, plausible dates.
• Ask explicitly for the awkward rows: Unicode names, apostrophes, very long strings, leading zeros, emoji, right-to-left text.
• Never use production data. Generated data that looks real is the point – it carries no personal information.
• Generate the data and the generator: ask for a Python or Java function so the next 10,000 rows cost nothing.
• Validate formats in code afterwards – a plausible-looking PAN or IFSC may not satisfy the checksum.

# ask the model for the generator, not the rows
import random

FIRST = ["Priya", "Arun", "Fathima", "Rajesh", "Meena", "D'Souza", "Shree"]
EDGE  = ["O'Brien", "Anne-Marie", "A" * 255, "Ravi 🙂", "  spaced  "]

def customers(n=1000):
    for i in range(n):
        name = random.choice(FIRST + EDGE)          # edge rows mixed into normal volume
        yield {"id": f"CUST-{i:06d}", "name": name,
               "mobile": f"9{random.randint(100000000, 999999999)}",
               "pin": f"{random.randint(110001, 849999)}"}

rows = list(customers(20))
print(sum(1 for r in rows if len(r["name"]) > 50), "long-name rows included")

Requirements analysis and defect prediction

Point the model at the requirement before the sprint starts – the cheapest defect is the one found in the story.

• Ask it to list ambiguities, missing error cases, undefined states and untestable statements.
• Ask “what questions would a tester ask in refinement?” – it produces a usable list in seconds.
• Defect prediction from history: cluster past defects by component to show where they concentrate. Useful for risk-based prioritisation.
• Summarise and de-duplicate incoming defects – the model is good at spotting that six reports are one bug.
• Treat every output as a hypothesis for a human to confirm. “The AI said this module is risky” is not evidence.

AI-assisted Selenium Java automation

Faster scaffolding, same engineering standards. The model writes the boilerplate; you keep the design.

• Good uses: page objects from a DOM snapshot, converting manual cases to skeletons, explaining a framework you inherited, writing the TestNG or Maven configuration.
• Bad uses: letting it invent locators it has not seen, or accepting Thread.sleep – it suggests that far too readily.
• Always give it the real DOM. Locators guessed from a description are fiction.
• Insist on explicit waits, your existing base class and your naming conventions – say so in the prompt.
• Review like any pull request. Generated code that compiles and passes can still be testing nothing.

// generated scaffold, reviewed and corrected by hand
public class CheckoutPage extends BasePage {

    @FindBy(id = "billing-first_name") private WebElement firstName;
    @FindBy(css = "[data-testid='place-order']") private WebElement placeOrder;

    public CheckoutPage(WebDriver driver) { super(driver); }

    public OrderConfirmationPage placeOrder(Customer customer) {
        type(firstName, customer.firstName());
        click(placeOrder);
        return new OrderConfirmationPage(driver);
    }
}

Playwright with TypeScript and AI

Playwright’s locator model suits AI assistance better than anything else in common use.

• Role- and test-id-based locators are stable and readable, so generated code needs less correction.
• Ask for the trace and the expect assertions, not just the clicks.
• Paste a failing trace or error into the model – it is genuinely good at reading Playwright errors.
• Codegen plus an AI clean-up pass is faster than either alone: record the journey, then ask for proper locators and assertions.
• Insist on web-first assertions (toHaveText, toBeVisible) instead of manual waits.

import { test, expect } from '@playwright/test';

test('member can reach checkout', async ({ page }) => {
  await page.goto('/qa-apps/shopkart/');
  await page.getByTestId('add-to-cart-1').click();
  await page.getByRole('link', { name: 'Cart' }).click();
  await expect(page.getByTestId('cart-count')).toHaveText('1');
});

API test generation with AI

The highest-return area: a specification goes in, a usable suite comes out.

• Feed it the OpenAPI or Swagger spec and ask for positive, negative, boundary, auth and schema tests per endpoint.
• Ask for the negative cases explicitly: missing required field, wrong type, expired token, wrong role, oversized payload, SQL in a string field.
• Request schema assertions, not just status codes – a 200 with the wrong body is the bug that gets through.
• Have it generate the data-driven table too, so one test covers twenty cases.
• Always check the generated contract against the actual response. Specs drift from reality.

@ParameterizedTest
@CsvSource({
    "'',            400, 'order id is required'",
    "ORD-1,         400, 'invalid format'",
    "ORD-999999,    404, 'not found'",
    "ORD-000123,    200, ''"
})
void orderStatusContract(String id, int status, String message) {
    given().auth().oauth2(token).queryParam("order_id", id)
    .when().get("/api/v1/orders/status")
    .then().statusCode(status)
           .body(status == 200 ? "status" : "error", notNullValue());
}

Self-healing locators and failure analysis

The feature every vendor leads with. Useful, and worth understanding before you trust it.

• A self-healing tool stores several attributes per element and, when the primary locator fails, picks the closest match by similarity score.
• That is helpful for cosmetic churn – a renamed class, a reordered div.
• It is dangerous when the element genuinely disappeared: the tool finds something similar, the test passes, and a real defect is hidden.
• Require every heal to be reported and reviewed. A silent heal is a suppressed failure.
• Failure analysis is the safer win: cluster last night’s 40 failures into 5 causes using the error text and stack traces.

AI test agents and CI/CD recovery

Where this is actually heading, and what is realistic to build today.

• Realistic now: triage agents that group failures, open tickets, and tell you which failures are infrastructure rather than product.
• Realistic now: exploratory agents that walk a journey and report what looked wrong – a second pair of eyes, not a regression suite.
• Realistic now: flaky-test detection from history, and an agent that proposes – never commits – the fix.
• Not realistic yet: unattended agents that maintain a suite, or that decide a release is safe.
• Every agent that touches CI needs the controls from Module 8: step limits, least privilege, approval before anything is merged or deployed.

Capstone: take one AI technique all the way through

1. Choose one practice application on this site and one technique from this track.
2. Measure the current state – how long the task takes you by hand, and the quality of the result.
3. Build it: the prompt, the schema validation, the script, the checks on the output.
4. Measure again on five fresh inputs. Record where it failed as well as where it helped.
5. Write it up in one page: problem, approach, numbers, limitations. That page is what you take to the interview.