Let's start with the Planner agent, which creates our test strategy based on the test application and business requirements.
Recall from station two, our test application is this student registration form. To automate this form, the Planner agent needs a configuration baseline. We are using SpiraPlan as that baseline platform to hold our requirements and our test cases. If you need a refresher on the configuration, station 1.2 covers all the steps for setting up your free SpiraPlan.
Now, looking under the requirements artifact, let's go to requirement 790. We see the user story has a description that states: the system must allow prospective students to fill out the registration form to submit their intake profile. Below the description, there are three acceptance criteria:
But as an SDET, we know this requirement is basic. It does not define validation rules for the mobile phone. It does not state what happens if mandatory fields are left blank, and it does not provide instructions for the location dropdowns.
On most projects, this is the moment when an engineer starts creating test scenarios — but we are building an autonomous pipeline. Therefore, let's see how we can use agentic intelligence to carry out shift-left testing.
Now we are inside VS Code. I have already created our Page Object Model files. In the next station, we will walk through the layout of this Page Object Model. So for now, remember the rule from station one: we must instruct our agents to respect our framework boundaries from the first prompt.
We are going to use the Spira MCP server to pull a requirement from Inflectra SpiraPlan. Then we will pass that data to the Playwright Test MCP Planner agent. The Planner will spin up a browser, navigate to our test application, and crawl the DOM tree to map out each field.
Here is the request: using the Inflectra Spira MCP server tool, retrieve the requirement data for requirement 790. Pass this requirement to the Playwright Test MCP Planner agent. Have the Planner crawl our live application at the test application practice form and analyze the requirements against the actual DOM layout. Generate a comprehensive testing strategy in a new folder called Test Artifacts. Your output must include:
Scenario-XX.The Spira MCP reads the requirement and the Playwright Test MCP opens a headless browser, scanning the elements. After a few moments, you will see files show up in this project.
I want to share a tip while the Planner agent executes. You might be thinking: typing out detailed instructions into Claude Code about Spira MCP, Playwright Test MCP, the requirement number, and the BDD feature file every time is going to get repetitive. You are right.
Later in the course, when we reach station five, I'm going to demonstrate how to orchestrate a specialized sub-agent. With a sub-agent, you can bypass writing this information into Claude Code over and over. You will be able to pass in the requirement number and the sub-agent will automatically change the tools and execute the prompts for you.
The Planner agent is complete and it operates as the exploratory tester, locking hands with Claude Code's capability as our business analyst. It is the best of both: a BA, which is Claude Code, reads the requirement, combined with the Planner agent, which is the tester, navigating to the application. I prefer to combine Claude Code with the Playwright Test Planner agent because AI clients such as Claude Code will guess page locators, but the Planner agent has insights on the locators.
Let's open up the generated files inside our test artifacts directory. Look at the results. It shows the name, testing strategy, requirement 790, the source requirements, the status, requirements as written, user story, acceptance criteria — and what the live DOM actually contains. The crawler interacted with the live form directly. We saw that it has 10 data fields, not three. The requirement only mentioned three. Now it has the locators. It shows first name is a required field, so are the last name and gender.
At this point, we see the requirement gaps and the missing business logic that we can go back to the product owner or the BA to ask questions about. Email contradicts its own acceptance criteria — that's right, it's a required field. The gender and programming language are required fields. The mobile has 10 digits. The date of birth has no bounds. Why? Because we could pick a day for any year, even a day in the future, as the birth date.
Clarifying questions for the product team. Additional test coverage. The P0s and the P1s and the P2s.
Now let's go to the BDD file. It respected our prompt constraint and formatted the test scenarios into Gherkin BDD syntax — the given, when, and then generated automatically for our test application. Look at some more of them. P1s, P2s, the 24 scenarios. And that's the P0 at the top, starting at 001.
The Planner agent has defined the what and the why of our quality strategy. For the what, it mapped the boundaries of our form by identifying the fields, data parameters, and required validation points. For the why, it connected those scenarios to our SpiraPlan user story, making sure each line is justified by a business requirement.
Now that the test plan is complete, we are ready to pass the blueprint on to take care of the how. Therefore, let's move on to the Generator agent.
Quiz
The quiz for this chapter can be found in 3.4.