| title | Test Automation |
|---|---|
| description | The QA Wolf agent automates E2E tests in Playwright (for web apps) and Appium (for iOS, Android, and Windows desktop apps). |
AI flow creation lets you create, edit, and debug flows by describing what you want in plain language, typed or spoken — you don't need to know the flow syntax to get started. To import a third-party library, just ask the agent for the package you need; it handles the process automatically.
This covers AI creation inside QA Wolf. To create flows from Claude Code, Codex, or another coding agent, see [QA Wolf MCP](/qawolf-mcp).It works best when you give the agent enough context to understand what you want and where to put it. It supports two ways of working:
No human in the loop. Front-load all the context into one prompt, hit run, and review the finished flow. A copilot workflow. Prompt for one small change at a time, discovering the app together with the AI.Both modes benefit from context you write down once. If you find yourself repeating the same background across sessions, put it in a custom skill.
In this mode the creation agent works unattended, so everything it needs to know has to be in the prompt before you hit run.
Vague prompts produce unreliable results. A prompt like "Create a test for the rate quote flow" gives the agent very little to work with. A stronger prompt includes:
- Where to start (URL and login credentials)
- What the user does, step by step
- What a successful outcome looks like
- Anything specific you want asserted
Example:
If there's something specific you need verified, say so. The agent won't always infer what matters to you — telling it what to assert produces more useful tests.
The agent writes each check that nothing later in the flow depends on as a soft check, so one failed check doesn't hide the rest.
If a flow depends on setup that is only explained in your documentation, include the link in the flow description or your prompt. The AI reads linked documentation before it starts building and uses it to complete configuration steps it cannot discover from the UI alone.
When the agent completes a flow on its own, the comment block at the top of the flow is its specification. Structuring that header around AAA tells the agent how far each verification should go.
For example, a flow that disables a feature could reload the page and check that the toggle is still off. It could also go further and sign in as a different user to verify the feature is no longer accessible. An AAA header states which one you want, so the agent doesn't have to guess:
/**
* Goal: Editor project transfers
*
* Test 1:
* Arrange: Log in as an enterprise owner and an enterprise editor. As the
* owner, enable editor project transfers in workspace settings under
* Privacy and Security.
* Act: As the editor, open the owner's project and go to project settings.
* Assert: The Move button is enabled.
*
* Test 2:
* Arrange: As the owner, disable editor project transfers.
* Act: As the editor, reload project settings.
* Assert: The Move button is disabled; check the tooltip content.
*/Before building a new flow, the AI searches your workspace for similar flows and reuses the parts that overlap instead of starting from scratch. Descriptive names help it find the right ones. If you want it to work from a specific example, point it at a working reference.
In this mode you stay in the loop, hand-holding the creation agent to completion. Use it when you don't have the full context yourself and are discovering the app at the same time as the AI, so it makes sense to work the problem together.
When adding code at a specific point in a test, beginning your prompt with "Insert code to" helps the agent understand it should add rather than replace.
Insert code to click the Submit button and wait for the confirmation message.
The agent inserts code relative to the current cursor position. If code ends up in the wrong place:
- Click on the line where you want the code inserted before prompting
- Or tell it explicitly: "Insert code on line 42 to..."
You don't need to tell the agent which Playwright locator to use. It's better at finding the most relevant locator itself. If you prescribe a locator and it turns out not to work, the agent gets stuck between obeying your instruction and producing a working test, and the result suffers.
Say "Click the Save button in the billing settings panel", not "Click page.locator('#btn-save-2')".
When targeting an element inside a container — for example, the first link within a specific panel — hover over the container for a second, then click the element. This gives the agent locators for both, and you can ask it to chain them:
Click the first link within the Recent Activity panel.
If you hover only on the element itself, the agent may use a less precise locator.
For interactions that produce a result (a download, a new page, a modal), trigger the action yourself first and let it complete. Then tell the agent what happened. This helps it understand the outcome, not only the selector.
Example:
- Click the download button and wait for the download to start
- Then prompt: "Click the download button"
A few phrases that help the agent understand what it's working with:
- "in the row" — when an element is inside a table row
- "file" — for file-related actions like clicking download or handling file inputs
For changes that apply across the entire test — updating all comments, removing hardcoded values, renaming variables — use "refactor" to signal that the change is global:
Refactor to replace all hardcoded email addresses with the TEST_USER_EMAIL environment variable.
If you need the agent to move a block of code, select all the lines you want moved before prompting. This removes ambiguity about what should be relocated.
If a run produces an error, you can ask the agent to address it without explaining the cause:
Fix the error.
The agent will read the error output and attempt a fix.
If you have a working example that you want the agent to follow, give it the path to that file and tell it what you'd like it to copy.
This will prevent having to re-describe the change each time.
For an iOS or Android app, the agent works on a device instead of a browser. It reads each screen from a screenshot and the app's element tree, then taps, swipes, and types its way through the journey. The flow it writes uses Appium. You can watch the device while it works.
The agent needs a build of your app: an .ipa for iOS, or an .apk or .aab for Android. Attach it to your message in place of a URL, and the agent's runs install it. To test every new build from your pipeline, see Mobile build testing. Upload builds lists every other way to get a build into QA Wolf.