A user story is a concise requirement statement that names a user perspective, desired capability, and resulting value. Acceptance criteria add the conditions that make the capability testable. section 4.4 section 11.2.1
A practical user story can combine:
- A role or perspective, such as “As a guest” or “As a timesheet user.” section 4.4 section 11.2.1
- A goal expressed as a capability, such as tracking time against projects or sending a request to an endpoint. section 4.4 section 11.2.1
- Acceptance criteria covering valid inputs, required data, response status, authentication, and failure behavior. section 11.2.1 section 11.2.2
Timesheet tracking
As a timesheet user, I want to track time against specific projects so that I can keep a history of time spent on individual projects. The associated constraints require half-hour units, a project and time amount, and private visibility. These details provide concrete conditions for a TDD loop and test design. section 4.4
API testing story
A branding-update story requires a PUT request to /branding/, valid JSON matching a Swagger schema, a 200 response for success, and a 400 response for bad or missing data. Those details support risks involving missing parameters, invalid types, malformed JSON, and endpoint errors. section 11.2.2
public static void main(String[] args) throws Exception {
List<String> corpus = loadFilesFromResources("data"); #1
String prompt = """ #2
You are an expert software tester that makes recommendations for #2
testing ideas and risks. You answer with suggested risks to test #2
for based on the provided user story delimited by three hashes and #2
user input that is delimited by three backticks. #2
Compile a list of suggested risks to test for, based on the user #2
story and the user input. #2
### #2
{relevant_document} #2
### #2
``` #2
{user_input} #2
``` #2
"""; #2
}
Use a user story as retrieved context for a testing prompt: delimit the story, combine it with a tester’s query, and request suggested risks grounded in both. section 11.2.1
