🟣 Marketplace QA

Model answer

I'd test it as a seller-side flow with a lifecycle and a moderation gate, not just a form. Creation: required fields, price and currency validation, image/media upload limits and formats, category selection, and prohibited-content rules. State machine: a new listing enters draft or pending-review, an approved listing goes live, a rejected listing returns to the seller with a reason and can be edited and resubmitted. I'd assert visibility at each state — a pending or rejected listing must not be buyer-visible or purchasable. I'd cover the abuse edges even here: duplicate listings, a price of zero or negative, and content that should trip moderation. And I'd check the seller dashboard reflects the correct state. The signal is that this is a moderated, stateful, seller-facing process whose outputs gate what buyers can eventually see.

Model answer

Unlike a single-seller charge, here one buyer payment must decompose exactly into platform commission, processing fees, taxes, and the seller's payout, so I assert the parts sum back to the buyer's total with no money created or lost. I'd test a matrix: different commission rates, items with and without tax, promotions that the platform vs the seller funds (who absorbs the discount changes the split), and refunds that must unwind the split correctly. Rounding matters because the split can leave a stray cent — I assert a documented rule for where it lands. Then the payout side: the seller's portion goes to escrow or to a payout schedule, not instantly, and I verify the timing and that a held payout isn't released early. I'd reconcile the platform's books — total in equals commission plus fees plus payouts plus refunds. The distinction from e-commerce/fintech single charges is the multi-party decomposition and the third-party payout, so that's where I focus the assertions.

Model answer

Payouts are conditional, so I test the release rules and the things that block them. Normal path: funds sit in escrow after purchase and release to the seller only when the condition is met — delivery confirmed, or a return window elapsed — and I assert the timing and that release is idempotent (a retry doesn't pay twice). Freeze path: an open dispute or a fraud flag on the order must freeze the payout even if the timer would otherwise release it, and lifting the dispute resumes the correct outcome. I'd test a dispute opened just before the scheduled release (a race against the timer), a partial release for a partially fulfilled order, and a chargeback arriving after release (which moves into claw-back territory). I'd reconcile escrow balances against held and released amounts. The principle is that the payout is reversible and conditional until its trigger, so I test both the release condition and every hold that can override it.

Model answer

The hard part is that the money has already left escrow, so recovery is a different mechanism than a simple refund. I'd assert the dispute resolution in favour of the buyer triggers a claw-back from the seller — debiting their balance or future payouts — and refunds the buyer correctly, with both sides' records consistent. The key edge is an insufficient seller balance: if the seller has withdrawn the funds, I test that the platform handles the shortfall per policy (negative balance, recovery from future sales, or platform absorbs it) rather than silently failing. I'd cover partial claw-back for a partial refund, a seller who disputes the claw-back, and a buyer dispute that's resolved in the seller's favour (no claw-back, payout stands). I'd reconcile that the platform's books balance across buyer refund, seller debit, and any platform loss. The signal is reasoning about money that's already disbursed and the two-sided, sometimes-unrecoverable nature of the correction.

Model answer

Fraud testing means I play the adversarial seller and verify the controls fire. I'd test account takeover and new-seller risk: a compromised or freshly created account attempting bulk listings or instant payouts should hit velocity limits and review gates. Listing abuse: fake or stolen-image listings, bait-and-switch where the delivered item differs from the listing, and prohibited items that should be caught by moderation. Manipulation: fake reviews and rating inflation, collusion between buyer and seller accounts to build fake reputation, and price manipulation. Payout fraud: a seller trying to trigger payout before delivery, or self-purchasing to extract funds. For each, I assert the relevant control triggers — moderation hold, velocity limit, payout freeze, or fraud flag — and that false positives have an appeal path. I'd also confirm fraud signals feed the payout-hold logic. The mindset shift is from 'does the legitimate flow work' to 'can a motivated bad actor abuse it', so I design cases around the abuse surface.

Model answer

An order has two stakeholders, so I test that their views converge no matter who acts. I'd drive each transition from the originating side and assert it propagates: the seller marks shipped and the buyer sees shipped with tracking; the buyer requests a return and the seller sees the request; a dispute opened by either party is visible and actionable to both; messages and timestamps match. I'd test concurrent actions — both sides acting on the same order at once — and assert deterministic, consistent resolution rather than a last-write-wins divergence. Stale-view cases matter: a buyer on an old page should get the current state on refresh, not act on outdated info. I'd verify notifications fire to the right party on each change. The failure class is divergence — one side's reality drifting from the other's — so the assertion is convergence of the shared order state across both viewpoints.

Model answer

The strategy has to acknowledge a real tension: longer escrow and stricter holds protect buyers but frustrate sellers who want fast payouts, and the platform lives in between. So I'd make the trade-off mechanisms the test targets. Buyer-protection controls: escrow held until delivery/return window, dispute freezes, fraud-driven holds, and reliable claw-back. Seller-speed controls: trusted-seller fast-track payouts, partial releases, and velocity limits that relax with reputation. I'd test the interactions where they collide — a fast-track payout to a seller who then gets a dispute (claw-back must work), and a hold that's too aggressive blocking a legitimate seller (appeal path). I'd gate releases on the integrity of these controls: escrow timing correct, freezes effective, claw-back solvent, fraud signals wired to payouts. I'd track two-sided metrics — buyer dispute-loss rate and seller payout latency — as the signals the strategy is balanced. As a lead I'd make the policy trade-off explicit with stakeholders so QA is validating an agreed balance, not an accidental one.