A municipal snow-plow story already has test conditions. Which GenAI design ask should the tester choose?
Select an answer to reveal the explanation.
Short Explanation
Conditions are the shopping list; cases are the recipes with “done when…” checks. Prompt GenAI for preconditions, inputs, and expected results—the oracle—not a monitoring wall. Clear expected results keep plow scenarios judgeable.
Full Explanation
When a municipal snow-plow story already has test conditions, the appropriate GenAI design ask is for cases that include preconditions, inputs, and expected results usable as oracles. Civic winter-operations testing needs executable cases whose expected results can judge pass or fail against public service rules, not dashboards or model-internal metrics alone. Asking only for a live monitoring dashboard with no cases or expected results fails because observability views do not create oracle-bearing test cases from conditions. Evaluating neuron coverage of a plow-routing LLM as the system under test fails by concept: the design task targets application cases for the snow-plow story, not white-box coverage of an assistant model. Deleting conditions because GenAI can supposedly execute without oracles fails because responsible design still needs expected results to evaluate civic plow behaviors. Exam caveat: design prompts should convert conditions into structured cases with oracle-ready expected results. Operational check: prompt GenAI from the city’s plow conditions, require precondition/input/expected-result columns, verify oracles against posted route policies, and only then promote cases into the municipal winter regression pack.