If you have ever stared at a blank test file not knowing where to start, ChatGPT prompts for Selenium tests can change your workflow completely.
In 2026, the best SDETs are not writing every line of automation code from scratch. They are using AI to accelerate test creation while applying their expertise to review and improve the output.
I have been doing this in my own SDET workflow for months. Here are the exact prompts I use — and the four rules that make them actually work.
4 rules before you start prompting
Before sharing the prompts, these four rules dramatically improve the quality of output:
1. Always specify your stack.
Mention Python or Java, Selenium 4, Pytest or TestNG, and any patterns like Page Object Model. Vague prompts produce generic code that needs heavy editing.
2. Give context about your application.
Tell ChatGPT what the page does, what elements are involved, what the expected behavior is. The more context, the more accurate the output.
3. Ask for one thing at a time.
Do not ask ChatGPT to write an entire framework in one prompt. Break it down — one page class, one test file, one utility function at a time.
4. Always review and test the output.
Never paste ChatGPT code directly into production without running it and understanding every line. This is non-negotiable.
The prompts
Prompt 1 — Browser setup and configuration
Use this when starting a new project and you need the initial browser configuration.
Write a Python Selenium 4 browser setup using pytest fixtures.
Include: Chrome WebDriver with ChromeDriverManager, headless mode option,
implicit wait of 10 seconds, and a teardown that closes the browser after
each test. Use the pytest conftest.py pattern.
What you get: A production-ready conftest.py with driver initialization and teardown. No more copy-pasting setup boilerplate across every new project.
Prompt 2 — Page Object Model class
Write a Python Selenium 4 Page Object Model class for a login page.
The page has: username field (id="username"), password field (id="password"),
submit button (id="login-btn"), error message (class="error-msg").
Include: explicit waits for each element, a login() method that takes
username and password as parameters, and a get_error_message() method.
Use pytest and inherit from a BasePage class.
What you get: A complete, clean POM class. Replace the locators with your actual application's element IDs and it works immediately.
Prompt 3 — Generating test cases from a POM class
I have a LoginPage POM class with these methods:
- login(username, password) — fills and submits the login form
- get_error_message() — returns the error text if login fails
- is_dashboard_visible() — returns True if login succeeded
Write a pytest test file with these scenarios:
1. Valid login redirects to dashboard
2. Invalid password shows error message
3. Empty username shows validation error
4. SQL injection in username field is handled safely
What you get: Four complete test cases with assertions, ready to run. You gave it the context — it writes the scenarios.
Prompt 4 — Locator strategy suggestions
I am testing a search feature. The search input has no ID or name attribute.
Available attributes: placeholder="Search products...",
data-testid="search-input", class="search-field active".
Which Selenium locator strategy should I use and why?
Write the locator in Python Selenium 4 syntax.
What you get: A reasoned explanation of locator priority (data-testid is most stable) plus the exact Python syntax. Useful when you are dealing with poorly structured HTML.
Prompt 5 — CI/CD pipeline for test automation
Write a GitHub Actions workflow file that runs a Python Selenium test suite
on every push to the main branch. The workflow should:
- Use Ubuntu latest
- Install Python 3.11
- Install dependencies from requirements.txt
- Install Chrome browser
- Run pytest with HTML report generation
- Upload the HTML report as a workflow artifact
What you get: A complete, working GitHub Actions YAML file. Drop it into your .github/workflows/ folder and your tests run automatically on every push.
Prompt 6 — Converting manual test cases to automation
I have this manual test case:
Test: Verify product filter by price range
Steps:
1. Navigate to /products
2. Set minimum price to 50
3. Set maximum price to 200
4. Click Apply filter
5. Verify all displayed products show prices between 50 and 200
Convert this to a Python Selenium 4 test using pytest and POM pattern.
Assume a ProductPage class with a set_price_filter(min, max) method exists.
What you get: A direct translation from manual to automated — extremely useful when you have a large manual test suite to migrate.
The 3 mistakes that kill your results
Not providing locator information.
Generic prompts produce locators like By.ID("submit") that will not work in your application. Always provide real element attributes.
Accepting the first output without refinement.
ChatGPT's first response is a starting point. The best results come from two or three rounds of refinement. Say "this is good but make the waits explicit and add a try/except for StaleElementException."
Asking for too much at once.
Prompts that ask for an entire framework produce messy, inconsistent code. Small focused prompts produce clean, maintainable output.
The mindset shift
The most effective way to use ChatGPT in a professional SDET workflow is not to replace your coding — it is to eliminate the parts that are repetitive and time-consuming so you can focus on the parts that require real expertise.
Framework design, test strategy, coverage decisions — those still need a human. Boilerplate, repetitive test variations, CI/CD scaffolding — that is where ChatGPT saves you hours every week.
Originally published with more prompts and examples at aitestingguide.com
Top comments (0)