A watershed rain-gauge user story is testable but has no condition list yet. Which GenAI prompt goal best fits test analysis?
Select an answer to reveal the explanation.
Short Explanation
The story is a trail map without trail markers. Ask GenAI to read the natural-language story and plant measurable, testable conditions along the path. A CI dashboard or model attack is a different hike entirely.
Full Explanation
A watershed rain-gauge user story that is testable but lacks a condition list is best served by a GenAI prompt whose goal is to interpret the natural-language story and emit measurable, testable conditions. Civic environmental monitoring depends on turning narrative intent into checkable statements before execution planning. Generating a live CI status dashboard for firmware builds fails by concept: continuous-integration visibility is an engineering telemetry concern, not test-analysis extraction of conditions from a story. Red-teaming the LLM with jailbreak payloads because the model is the product under test fails because the scenario targets analysis of the rain-gauge application basis, not adversarial evaluation of the assistant model. Replacing conditions with vendor SKUs for cloud model hosting fails because commercial hosting identifiers are procurement artifacts, not measurable behavioral conditions derived from the watershed story. Exam caveat: align the GenAI analysis goal to the ISTQB-style analysis need—here, condition identification—rather than nearby DevOps or LLM-security tasks. Operational check: feed the municipal rain-gauge story to GenAI with an explicit “emit measurable conditions” ask, have a hydrology SME reject untestable lines, and file the surviving conditions into the civic coverage backlog before design techniques are chosen.