How QA Testers Are Actually Using AI in 2026 (Prompts Included)

Aleksandr Singer — Fri, 17 Jul 2026 00:55:09 +0000

How QA Testers Are Actually Using AI in 2026 (Prompts Included)

Every few months a new wave of "AI will replace testers" takes shows up in my feed, followed by an equal and opposite wave of "AI can't understand testing at all." Both miss what's actually happening on the ground.

Here's the real shift: testers who write clear, specific prompts are getting noticeably more done in the same hours. Testers who type "write me some test cases" and expect magic are getting the same generic, useless output everyone else gets from lazy prompting.

The gap isn't the AI. It's the prompt.

Why generic AI advice doesn't work for QA

Most "prompt engineering" content out there is written for marketers and content creators. It teaches you to get better blog outlines and better ad copy. None of it teaches you how to get an AI to think about boundary values, race conditions, or regression risk — because none of it was written by someone who does this job.

Ask an AI assistant to "write test cases for the login feature" and you'll get five happy-path cases and maybe one password-mismatch case. Technically test cases. Practically useless.

What a genuinely useful QA prompt looks like

Compare that to something like this:

"List test cases for [FEATURE] specifically covering concurrency and race conditions where multiple users act on the same resource."

That one prompt forces the AI out of happy-path mode and into the territory that actually breaks production — two users editing the same record, a double-submit on a slow connection, a webhook firing twice. It's not a smarter AI. It's a smarter question.

The pattern holds everywhere in QA: the more your prompt encodes an actual testing concept (boundary values, negative space, regression blast radius), the more useful the output. Generic prompts get generic test cases. Specific prompts get the kind of test cases a senior tester would actually write.

The bigger shift

This mirrors what's happening industry-wide. AI is increasingly handling the repetitive execution layer of QA — drafting the first pass of test cases, structuring a messy bug report, generating boilerplate test data — while the tester's job shifts toward two things: asking for the right thing, and critically reviewing what comes back before trusting it. Neither of those is optional. An AI-drafted test plan that nobody checks against the actual system is just a faster way to miss things.

That second part matters as much as the first. Treat AI output here the way you'd treat a junior tester's first draft — a useful starting point, never the final answer.

If you want the full set

I put together a toolkit of 40 of these — organized into test case generation, edge-case brainstorming, bug report drafting, regression/risk analysis, test data generation, and exploratory testing charters — plus a couple of tools that make the difference between "AI slop" and something you'd actually ship: a checklist for verifying AI output before you trust it, and a context primer that sharpens every prompt's results by giving the AI your actual project details up front.

Check out the AI Prompt Toolkit for QA Testers & SDETs →

Breaking Into Software QA

Aleksandr Singer — Fri, 10 Jul 2026 23:46:04 +0000

Testing a Login Feature the Way You'd Actually Do It on the Job

A lot of QA content teaches testing techniques in isolation — here's equivalence partitioning, here's boundary value analysis, here's how to write a bug report. All useful, but it rarely shows how those pieces come together on a single, real feature.

So here's one walkthrough, start to finish: testing a login feature manually, at the API level, and with automation — the way you'd actually approach it with a sprint deadline, not in a vacuum.

The feature

A web and mobile app lets a user log in with an email and password. On success, they land on a dashboard. After 5 failed attempts within 10 minutes, the account locks for 15 minutes.

Simple on the surface. There's more here than "type password, click button."

Step 1: Manual test design

Before touching a keyboard, map out what actually needs checking:

Happy path: valid email + valid password logs in successfully
Boundary: exactly 5 failed attempts triggers lockout; 4 attempts does not
Negative: wrong password, non-existent email, empty fields, SQL-injection-style input in the email field
Session: does refreshing the page keep the user logged in? Does logging out on web also affect the mobile session?
Mobile-specific: biometric login after the first successful password login, app backgrounded mid-login

That boundary case — exactly 5 attempts vs. 4 — is the kind of thing that's easy to skip if you're only thinking in terms of "test the lockout feature" rather than testing the number itself.

Step 2: API-level tests

UI tests are slow and brittle compared to hitting the API directly. Before automating anything visual, these are worth locking down at the API layer:

POST /login with valid credentials returns 200 and a token
POST /login with invalid credentials returns 401, not 500
POST /login six times in a row returns 423 (locked) on the 6th attempt
A request with an expired token returns 401, not a silent failure

That third one matters more than it looks. A refactor that accidentally changes the lockout threshold, or breaks it entirely, is exactly the kind of regression that a UI-only test suite tends to miss — because the UI still looks fine right up until someone tries to actually break in.

Step 3: What to automate vs. keep manual

Not everything here deserves the same treatment.

The happy path and the lockout boundary are stable, high-value, and get exercised on every release — strong candidates for automation at both the API and UI level. A minimal Page Object for this might look like:

# pages/login_page.py
from selenium.webdriver.common.by import By
from pages.base_page import BasePage

class LoginPage(BasePage):
    EMAIL_INPUT = (By.ID, "email")
    PASSWORD_INPUT = (By.ID, "password")
    LOGIN_BUTTON = (By.CSS_SELECTOR, "button[type='submit']")
    ERROR_MESSAGE = (By.CLASS_NAME, "error-message")

    def login(self, email, password):
        self.type_text(self.EMAIL_INPUT, email)
        self.type_text(self.PASSWORD_INPUT, password)
        self.click(self.LOGIN_BUTTON)

    def get_error_text(self):
        return self.find(self.ERROR_MESSAGE).text

# tests/test_login.py
def test_account_locks_after_5_attempts(driver):
    login_page = LoginPage(driver)
    driver.get("https://example.com/login")
    for _ in range(5):
        login_page.login("user@example.com", "wrong-password")
    login_page.login("user@example.com", "correct-password")
    assert "locked" in login_page.get_error_text().lower()

Meanwhile, usability observations — is the lockout message actually clear to a first-time user? — and one-off exploratory checks are better left manual. They rely on human judgment, not a pass/fail assertion, and automating them just gives you a brittle test that doesn't actually check the thing you care about.

Step 4: Prioritizing under time pressure

If a release is tomorrow and there's only time for a fraction of this list, the lockout boundary and the API-level auth checks go first. They protect account security, and they're exactly the kind of thing that quietly breaks when someone refactors the login service — and exactly the kind of bug that reaches production unnoticed if the only thing being checked is the UI happy path.

The pattern, generalized

Strip away the login specifics and the shape underneath is reusable for almost any feature:

Design test cases across happy path, boundaries, and negative cases
Identify what can be verified faster and more reliably at the API layer
Decide what's actually worth automating vs. what needs a human's judgment
When time is short, prioritize by what protects the business most, not what's easiest to test

That's the difference between "I know some testing techniques" and "I can design a test strategy for a real feature" — and it's the second one that actually gets asked about in interviews.

This walkthrough is adapted from a chapter in Breaking Into Software QA, a complete guide to breaking into software QA — manual and automated testing, API testing, mobile/Appium, real working automation code, and a full job search roadmap.

DEV Community: Aleksandr Singer

How QA Testers Are Actually Using AI in 2026 (Prompts Included)