7 Prompt Engineering Practice Every Tester Should Know

Artificial Intelligence has become part of many Testers’ daily workflows. We use it to generate Playwright scripts, analyze HTML, explain production bugs, review automation code, and even help investigate failed pipelines.
Many testers still say: “AI-generated automation isn’t reliable.”
After working with AI for quite some time, I’ve realized something interesting.
The biggest difference between amazing AI output and disappointing AI output usually isn’t the model. It’s the prompt.
When I first started using ChatGPT for Playwright automation, I treated it like a code generator. I’d paste a User Story and ask: “Generate script testing function ‘Login page'”. Sometime the expected result is mapping with my thought but sometimes it made me so confused because of many informative data in suggested.
Today my workflow is completely different. Instead of asking AI to write code immediately, I guide it through the same process that I would follow if I were implementing the ticket myself.

In this article, I’ll share the practical prompt engineering that have consistently helped me generate cleaner, more maintainable Playwright automation. Rather than focusing on complex AI concepts, these points are based on the everyday workflow of a Tester and can be applied immediately in your own projects.

I used to paste an entire User Story into Gemini’s textbox and ask: “Please write the test cases to cover this User Story”. Later, while reviewing the ticket, I’d notice the acceptance criteria never not mentioned invalid credentials or session timeout, some cases are unnecessary. That’s when I stopped asking AI to write test case first.
One common mistake when using AI is asking it to generate immediately after reading a User Story. However, experienced testers know that poor requirements lead to poor checklist. If the User Story is unclear, the generated test script will also be incomplete. Instead of jumping straight into coding, ask AI to review the requirement first.

Example:
Instead of asking:
Generate Playwright script for this User Story.
Ask AI to review the requirement first:
Act as a Tester, review the following User Story and Acceptance Criteria.
Identify:
1. Ambiguities
2. Missing acceptance criteria
3. Missing validations
4. Risks
5. Edge cases
6. Question to ask Business Analyst

By spending just a few minutes reviewing the requirement with AI first, you can identify missing scenarios early and design more complete, maintainable tests.

I made this mistake for months before realizing what was wrong when asking AI to solve a problem before explaining the environment.
Imagine a new developer joining your team.
Would you immediately say, “Build the Login Page.”
You would first explain. Instead of: “Generate Playwright code for Login “
Try with this:

Project:

• Playwright + TypeScript
• Page Object Model
• Existing BasePage

Task:
Look at the user story and create automation script for Login feature

Done Criteria:

• Redirect to dashboard
• User profile visible
• No validation error

Constraints:

• No hardcoded waits
• Use existing BasePage methods
• Follow coding standards (PEP8)
• Follow best locator strategy to locate element.

One habit that significantly improved my prompts was asking AI to analyze the problem before writing any code.
Instead of treating AI like a code generator, I ask it to think through the implementation first.

For example:
– Analyze the User Story
– Suggest the most stable locators
– Identify possible synchronization issues
– Recommend reusable Page Object methods
– Explain the assertion strategy
– Highlight potential flaky scenarios

And then generate:
– Page Object
– Test Script
– Locator explanation
– Assertion explanation

The resulting code is usually much cleaner because AI has already considered the design decisions.

Many prompts explain what to do but forget to explain what a successful solution looks like.
For example:
Automate Login.
AI doesn’t know whether success means:
– Redirect to Dashboard?
– Display username?
– Receive authentication token?
– Cookies created?
– Session stored?

A better prompt would be:
After clicking Login
– Dashboard page opens
– URL/ contains/ dashboard
– User avatar becomes visible
– Welcome message appears
– No validation errors displayed

=> Now AI knows what to verify and this often produces better assertions automatically

When writing prompts, most people focus on explaining what they want AI to do, but they often forget to specify what AI should avoid.

Whenever a prompt leaves room for interpretation, AI will try to fill in the missing information based on patterns it has learned from many different projects. As a result, the generated solution might technically work, but it may not follow your team’s coding standards or automation best practices.

For example, imagine you ask AI to generate a Playwright test without providing any constraints. Since AI doesn’t know your project’s conventions, it may choose XPath selectors, add wait_for_timeout() calls, duplicate logic across multiple methods, or hardcode test data directly into the script. While these choices may solve the immediate problem, they often make the test suite harder to maintain and more likely to become flaky over time.

Instead of assuming AI will make the same design decisions you would, explicitly define the rules it should follow.

Constraints:

• No waitForTimeout()
• Prefer data-testid selectors
• Reuse existing Page Objects
• Follow coding standards
• No duplicated methods
• Externalize test data
• Handle synchronization properly

As you gain more experience using AI, you’ll notice that high-quality prompts are not necessarily longer. They are simply more specific. A short prompt with well-defined constraints often produces better results than a long prompt filled with vague instructions.

Looking back, expecting AI to do everything in a single prompt. It was probably the biggest reason my prompts produced inconsistent results. For example, they might ask:
Generate Playwright automation for the Login feature.
Include:
– GitHub Actions pipeline
– Test cases
– Page Object
– API validation
– SQL verification
– Test data
– Documentation
– GitHub Actions pipeline

Technically, AI can answer this request. But in most cases, the result is too generic, difficult to review, and often misses important details. The problem isn’t the AI. The problem is that we’re asking it to solve too many problems at once.
When implementing a new feature, do you complete everything in one step? Probably not. A typical workflow looks more like this:
1. Read the User Story
2. Review Acceptance Criteria
3. Design Test Scenarios
4. Inspect the HTML
5. Choose the Best Locators
6. Create the Page Object
7. Write the Test Script
8. Review and Refactor

Why This Works
Breaking a complex task into smaller prompts has several advantages:
– AI stays focused on one objective at a time.
– The responses are more detailed and easier to understand.
– You can validate each step before moving to the next.
– It’s easier to correct mistakes without starting over.
Most importantly, you’re working with AI instead of expecting it to solve the entire problem in one go.

One lesson I’ve learned is that AI-generated code should never be merged into a project without review. Even when the automation looks correct, small issues can make a test unstable or difficult to maintain.

Instead of asking “Does the script work?”, review it the same way you would review a pull request from another engineer.

I usually ask AI a second round of questions after it generates the code:

Review this Playwright automation.
Identify:

• duplicated logic
• unnecessary waits
• weak assertions
• unstable locators
• code that doesn’t follow PEP8
• maintainability issues
• possible flaky scenarios

This review often finds issues that were easy to miss during the initial generation. In many cases, the first version of the script works, but the reviewed version is cleaner, easier to maintain, and more consistent with the rest of the framework.

One mistake I made early on was trusting code simply because it looked clean. Several times the script executed successfully but failed to follow our framework standards or covered the wrong business scenario. That experience taught me that AI-generated code still requires the same level of review as any pull request created manually.

If there’s one thing I’ve learned, it’s this: the quality of AI output usually reflects the quality of the conversation you have with it.

I no longer think of ChatGPT as a tool that writes Playwright tests for me. I think of it as another engineer in the room. One that asks questions, reviews ideas, and helps me iterate faster.

That’s the mindset that has made the biggest difference in my own workflow, and I hope these principles help you build one that works for yours.

Stable locators, meaningful assertions, maintainable Page Objects, and well-designed test cases are still the foundations of a reliable automation framework. AI simply helps us build these things faster.
The difference between receiving generic code and production-ready automation often comes down to a single factor: the quality of the prompt.

As AI continues to evolve, writing effective prompts will become an increasingly valuable skill for every Tester. Learning how to communicate effectively with AI is no longer just a productivity hack; it is becoming an essential part of modern testing.