How do you use LLMs in day-to-day testing work responsibly?

LLM assistants (chat tools and IDE assistants such as GitHub Copilot or similar) are now a normal part of testing work. Using them for drafting with human review is established practice. Interviewers want to hear that you get value from them and stay accountable for the result.

Where they help

• Test idea generation. Give the assistant a user story and acceptance criteria and ask for positive, negative, boundary and error scenarios. It is good at producing a broad first list quickly. I then prune duplicates, add domain-specific risks it couldn’t know about, and prioritise.
• Test data. Realistic names, addresses in several locales, invalid email formats, Unicode edge cases, JSON payloads matching a schema.
• Boilerplate code. Page object skeletons, REST Assured request setup, fixtures, a GitHub Actions workflow draft, converting a curl command into test code.
• Understanding code. Explaining an unfamiliar regex, a legacy test, or a stack trace. Summarising a long log is useful as a starting point, but the conclusion still needs checking.
• Writing. First drafts of bug reports, test plans and release notes that I edit.

How I get good output

Context is everything. A vague prompt gives generic tests. I include:

• the requirement or acceptance criteria;
• an example of an existing test in our framework, so it follows our conventions (locators, helpers, naming);
• constraints (“use explicit waits, no Thread.sleep”, “Selenium 4 Java, JUnit 5”).

Here is our acceptance criteria for password reset (pasted below) and an
existing test from our suite for style. List negative and boundary scenarios
we have not covered, as a table: scenario, input, expected result, risk.
Do not write code yet.

Asking for scenarios first, then code for selected ones, gives me a review checkpoint before anything lands in the codebase.

How I review

I treat output like a pull request from a new team member:

• Does it test the actual requirement, or a plausible-sounding one?
• Do the assertions check outcomes, or just that “something exists”?
• Do the APIs and methods it used actually exist in our library versions? Assistants sometimes invent methods or use deprecated ones.
• Does it run, and does it fail when the feature is broken? I often break the code or data deliberately to confirm the test catches it.

Guardrails

• Only use tools approved by the company, and never paste credentials, production data, customer PII or confidential code into unapproved services.
• Don’t let assistant output bypass normal code review.
• Keep ownership: “the AI wrote it” is not an explanation for a bad test.

What interviewers look for

• Specific, realistic use cases rather than vague enthusiasm.
• A clear review process, including checking that tests can fail.
• Awareness of data privacy and hallucinated APIs.

Common mistakes

• Claiming the assistant “writes all our tests”.
• Accepting a large generated suite without reading it, which creates maintenance debt and false confidence.