Testers validating the park-and-recreation permit site only exercise successful purchase paths. What should they add to strengthen security testing?
Select an answer to reveal the explanation.
Short Explanation
Happy paths show the front door works; misuse cases try the windows. Stack coupons, poke other people's permit IDs—that's how you catch abuse. Scrapbook shots, auth-blind load tests, and button surveys don't replace that.
Full Explanation
Misuse-case (abuse-case) testing deliberately exercises hostile or unexpected behaviors that happy-path testing never touches. For a park-and-recreation permit site, that includes coupon stacking beyond intended limits, insecure direct object references against other citizens’ permit record IDs, privilege escalation, and parameter tampering. Adding those cases strengthens security testing because authorization and business-logic flaws typically appear only when testers act like abusers rather than satisfied customers completing a successful purchase.
Additional happy-path screenshots for a project scrapbook document success aesthetics, not security resistance. Performance tests that ignore authorization may prove load capacity while remaining blind to IDOR and privilege bugs that scale with traffic. Usability surveys about button placement improve UX but do not evaluate whether access controls and fee rules survive adversarial input.
Exam caveat: Domain 6 and secure software testing emphasize misuse/abuse cases alongside positive tests. When stems say testers ‘only’ exercise successful paths, the missing piece is hostile-case coverage—not more documentation of success.
Operational check: Expand the park permit test plan with named misuse cases (stacking, negative quantities, horizontal IDOR on permit IDs, replay of paid tokens), automate where practical, require fail/pass evidence before go-live, and track residual high-risk logic issues into remediation with owners.