QA Exercise 9

Exercise · Bug Hunt (User Roles & Permissions)

QA · Hands-on

Create users, assign roles, toggle permissions, and run an access check. Find defects in role mapping, permission toggles, deletion, duplicate emails, impersonation, and summary counts. Report via STR → Expected vs Actual → Severity/Priority → Recommendation.

Intentionally buggy: role→permissions mapping inverted, toggles sometimes flip after save, deleting a user removes the next row, duplicate emails allowed, blank user allowed, impersonation checks the wrong user, “Admin-only” action sometimes passes for viewers, counts desync.

Name Email Role 0 users

NameEmailRoleReadWriteActions

Access check:

🎯 Instructions (Oral) task flow

Add three users: Admin, Editor, and Viewer. Also add a blank name or duplicate email to test validation.
Toggle permissions so the Viewer has no write access and the Admin has both read/write.
Click Save changes and see if toggles stay consistent or flip.
Select the Viewer, click Impersonate… and run the Admin-only action. Note whether it is allowed.
Delete the second user; observe which row actually disappears and whether the count updates correctly.
Present your spoken bug report: Title → Steps to Reproduce → Expected vs Actual → Severity/Priority → Recommendation.

📖 Vocabulary definitions

role-based access control (RBAC) — permissions are granted based on a user’s role (Admin, Editor, Viewer).
privilege escalation — gaining higher permissions than intended.
authorization — deciding what an authenticated user is allowed to do.
permission toggle — a switch enabling/disabling an ability (e.g., write).
idempotent save — saving multiple times produces the same stored state.
impersonation — acting as another user to verify access behavior.
data integrity — data remains accurate, consistent, and valid.
uniqueness constraint — a rule preventing duplicate values (e.g., email).

🧩 Collocations natural pairings

assign a role / revoke access
enforce uniqueness / validate input
persist permissions / verify changes
prevent privilege escalation / lock down admin actions
bind actions to IDs / avoid index-based deletes

🗣️ Idioms & Phrasal Verbs natural speech

slip through — get accepted when it shouldn’t: “Duplicate emails slip through.”
flip back — revert unexpectedly: “Write access flips back after save.”
lock down — secure or restrict: “Lock down admin-only endpoints.”
track down — locate the cause: “Track down the off-by-one delete bug.”
line up with — match: “Displayed permissions don’t line up with stored values.”

🎤 Model Answer (spoken style) example

Bug title: Permission model allows privilege escalation; save is not idempotent; delete removes the wrong row; duplicate/blank users accepted; impersonation targets the wrong user.

Steps to reproduce: Add Admin, Editor, Viewer. Also add a blank user and duplicate email. Disable write for Viewer, enable read/write for Admin. Click Save. Select Viewer and run the Admin-only action via Impersonate. Delete the second user.

Expected result: Uniqueness and required fields enforced; toggles persist reliably; Viewer cannot perform admin actions; delete removes the selected row; counts match.

Actual result: Duplicate/blank users slip through; after saving, toggles flip back; Viewer is allowed to run the admin action; deleting the second user removes a different row; the user count desyncs.

Severity / Priority: Critical (P0) — security breach risk from privilege escalation and inconsistent authorization.

Recommendation: Enforce server-side validation (required + unique email), map role→permissions correctly, make save idempotent, bind delete to stable user IDs, ensure impersonation uses the selected user, and compute counts from the canonical list.