A benefits eligibility calculator for residents is built with a strong Extreme Programming influence. Which distinguishing XP emphasis should the team protect for verifying features with the customer’s voice?
Select an answer to reveal the explanation.
Short Explanation
XP wants the ‘customer voice’ baked into tests—like a recipe card the kitchen keeps checking. Those customer/acceptance tests steer the build early, not a giant surprise tasting at the end. That’s a hallmark XP engineering vibe.
Full Explanation
A benefits eligibility calculator built with a strong Extreme Programming influence should protect customer tests / acceptance tests that express expected behavior and guide development continuously. XP distinguishes itself with technical and customer-facing verification practices that keep the customer’s voice in executable or explicit tests, not only in late gates. That emphasis helps civic benefits logic stay aligned with policy expectations as code evolves and reduces surprise failures at release.
Deferring all testing until a final predictive UAT gate after six months of coding fails conceptually because it abandons XP’s continuous verification stance for a late predictive gate. Letting only the Scrum Master write tests without customer involvement fails because Scrum Master facilitation is not a substitute for customer or acceptance tests expressing expected behavior. Replacing automated checks with informal hallway opinions and no documented criteria fails because undocumented opinions do not provide the guiding acceptance tests XP emphasizes.
Exam caveat: At CAPM depth, associate XP with customer/acceptance tests and related engineering practices—not with deferred UAT-only or Scrum Master-only testing myths. Operational check: express eligibility rules as acceptance tests with policy stakeholders, run them continuously in the pipeline, and refuse to call features done when customer tests fail.