🟢 SaaS QA

Model answer

I'd seed two fully isolated tenants, A and B, each with known records. As tenant A I'd first confirm normal flows return only A's data. Then I'd take a known resource ID belonging to B and request it directly via the API — GET, and also PUT/DELETE — asserting a 403 or 404 every time, never B's payload. I'd repeat across list, detail, search, and export endpoints, because isolation often holds on the obvious read path but leaks through search or a bulk-export query that forgot the tenant scope. The mental model I'm testing is 'is there a tenant_id in the WHERE clause of every query', so I treat any cross-tenant 200 as a data breach, not a cosmetic bug.

Model answer

I'd model it as a state machine: trial-active, trial-expiring-soon, converting, paid, and expired. For each I assert the correct feature access and the correct billing state. Key cases: convert before expiry — paid features unlock and the first invoice is correct; convert with a declined card — access stays at trial level and a clear retry path appears, no paid unlock; trial expires with no action — access drops gracefully on the next request, not a 500, and any in-flight authenticated session is handled cleanly; convert exactly on the expiry boundary — no double-charge or gap. I'd also check that downgrade-from-trial doesn't strand data the user created during the trial. The thread through all of these is that access level and billing state must change together and atomically.

Model answer

First I'd nail determinism: pick a user bucketed into the ON cohort and reload many times, across sessions and devices, asserting the value never flips — sticky assignment is the property that makes a percentage rollout safe. Then I treat OFF as a real test path: every flag-gated feature needs its OFF behaviour verified, because that's what most production users see. I'd seed users explicitly into each cohort rather than relying on the rollout percentage to eventually give me one. I'd test the transitions too: flipping the flag OFF mid-session should remove the feature on the next page load without a forced sign-out, and I'd confirm the flag cache invalidates so users don't keep a stale value until a TTL expires. Finally I'd run an ON/OFF smoke pass on deploy so a flag regression in any gated feature is caught at once.

Model answer

I'd anchor every assertion to the billing cycle. On upgrade mid-cycle: access to the higher tier is immediate, and the invoice shows a prorated charge for the remaining days, not a full second period. On the later downgrade: I check the product's rule — does the lower tier take effect immediately with a prorated credit, or at period end? — and assert seats above the new limit are handled per that rule (locked, not deleted, and the user is told). I'd test the boundaries: upgrade on day 1, on the last day, and exactly at renewal; downgrade when current seat usage exceeds the target tier. I'd verify the audit log captures each plan-change event for support, and that no race between the plan-change event and the payment webhook double-charges. The domain signal is that proration is about days-in-cycle and seat limits, not abstract min/max values.

Model answer

I'd enumerate every role and every sensitive endpoint and treat the cross-product as a parametrised test: for each role × endpoint, the expected result is either allowed (200 with data) or denied (403), and I assert exactly that. The subtle failure I specifically design for is the silent 200 — a Member calling an Admin-only endpoint and getting 200 with an empty array instead of 403. That reads as success to a client and hides a broken permission check, so I assert the status code, not just the absence of data. I'd test with a valid token for the wrong role, not an anonymous request, because the bug is usually 'authenticated but under-privileged'. I'd run this matrix in CI so adding an endpoint without a permission check fails the build. UI checks are a usability nicety; the API matrix is the proof.

Model answer

I start from the contract: most webhook providers guarantee at-least-once, not exactly-once, so duplicates and retries are normal, not edge cases. I'd send the same event twice with the same event ID and assert the second is ignored — same final state, one record, one side effect. I'd send events out of order (an update before its create) and assert the system either reconciles or rejects deterministically. I'd simulate a delayed retry arriving after later state has changed and assert it doesn't clobber newer data. I'd also test the signature/verification path and a malformed payload. Tooling-wise I'd stub the provider with WireMock to drive delay, duplicate, and failure. The whole suite is built on the assumption that the network will deliver the same message again, so idempotency is the property under test.

Model answer

I'd rank risk by blast radius. Top tier: cross-tenant isolation — a regression here is a compliance breach across every customer, so that suite is a hard release gate and runs on every build. Next: billing lifecycle smoke in the payment sandbox (trial → paid → upgrade → downgrade → cancel), because billing bugs hit revenue and retention directly. Then feature flags: an OFF-path pass for every gated feature, since most users see OFF, plus deterministic-assignment checks. Then the RBAC matrix as a data-driven suite. I'd layer this — unit and contract tests for the cheap fast feedback, integration for tenant scoping and webhooks, a thin E2E layer for the critical billing and onboarding journeys. I'd explicitly de-scope exhaustive manual regression in favour of the automated matrices, because tenants and flags multiply combinatorially and manual coverage can't keep up. Each gate has a clear pass/fail so the release decision is evidence-based.

Model answer

The core problem is combinatorial: roles × endpoints × tenants × flags. I'd attack it on several fronts. First, generate the matrices from one source of truth — the permission model and the flag registry — so adding an endpoint or flag automatically extends coverage and a missing check fails CI; hand-written tests rot here. Second, apply pairwise/combinatorial reduction for flag interactions so I cover interaction defects without the full cross-product. Third, push correctness down: contract tests at the tenant-scoping and integration boundaries catch isolation and webhook regressions far cheaper than E2E. Fourth, keep a thin, stable E2E layer only for the few business-critical journeys (billing, onboarding) and invest in flake control so the suite stays trusted. Organisationally, I'd make the isolation and RBAC matrices non-negotiable gates and assign ownership so coverage is maintained as flags are retired, not just added. The goal is a net whose cost grows sub-linearly with the product's combinatorial surface.