تولیدکننده تست موارد مرزی: توصیف یک ویژگی را به یک ماتریس تست کامل پیش از نوشتن کد تبدیل کنید
چرا این پرامپت اهمیت دارد
Engineering teams that start coding directly from a short ticket typically discover 30-40% of their real edge cases only after a customer hits one in production. On a feature that touches money and inventory, each edge case that ships unhandled turns into a support escalation, an engineering fire drill, a reconciliation headache for finance, and in the worst cases — like the double-refund or stale-pricing scenarios above — direct, hard-to-reverse financial loss. Finding these gaps on paper during planning costs minutes; finding them in production after a customer or auditor does costs hours of firefighting plus the trust damage of a visibly broken checkout flow.
ما از آن برای چه استفاده می‌کنیم
A backend engineer is about to implement a new bulk order cancellation endpoint for an e-commerce API — one function call that touches payment refunds, inventory restocking, and customer notifications at once. The ticket describes the happy path in two sentences. Before writing a single line of code, the engineer runs this prompt against the feature description to surface every edge case, race condition, and integration failure the implementation needs to handle.
پرامپت
Role: Act as a senior software engineer and QA architect with deep experience in test design and failure-mode analysis for production systems. Context: I am about to implement the following feature or function, and I want a complete picture of what could go wrong before I write any code. Feature description or function signature: [PASTE FEATURE DESCRIPTION OR FUNCTION SIGNATURE HERE] Language/framework: [E.G. "PYTHON WITH FASTAPI", "TYPESCRIPT WITH NODE.JS"] Edge cases I've already planned for: [LIST THEM, OR WRITE "NONE YET"] Domain constraints or sensitivities: [E.G. "TOUCHES PAYMENT PROCESSING", "MUST BE IDEMPOTENT", "RUNS ACROSS MULTIPLE WORKERS", OR "NONE"] Task: Produce a complete test matrix for this feature, organized into these six categories: 1. Happy path - the 1-3 cases representing normal, expected usage 2. Boundary conditions - empty inputs, maximum sizes, zero/negative values, type edge cases 3. Invalid/malformed input - what a malicious or confused caller might send 4. State and concurrency edge cases - what happens if this runs twice, runs concurrently, or runs when upstream state changes mid-execution 5. Integration failure points - what happens when each external dependency (database, API, queue, cache) times out, errors, or returns a malformed response 6. Silent failure risks - cases where the code might succeed technically but produce the wrong result without throwing an error For each test case, give: a one-line description, the specific input/state that triggers it, and the expected correct behavior. Constraints: Do not give generic testing advice - every case must be specific to the actual feature described above. Flag the 3-5 cases you consider highest risk if left untested, with a one-sentence reason why. If the feature touches money, user data, or irreversible actions, call that out explicitly and treat those paths with extra scrutiny. Output Format: Present the test matrix as a numbered list within each of the six categories above. After the full matrix, add a short "Top 5 Risks If Skipped" section ranking the highest-priority gaps.
نتیجه
Feature: Bulk order cancellation endpoint (cancels up to 50 orders in one call, triggers payment refunds, restocks inventory, sends customer notifications).
1. Happy Path
- Cancel 3 valid, unshipped orders belonging to the requesting user → all 3 refunded, restocked, and notified successfully.
- Cancel a single order via the bulk endpoint with a 1-item array → behaves identically to the single-cancel endpoint.
2. Boundary Conditions
- Empty order ID array submitted → should return a 400 with a clear message, not a silent no-op.
- Exactly 50 order IDs (the stated max) → should succeed; 51 should be rejected with a specific "limit exceeded" error, not a generic 500.
- Duplicate order ID appears twice in the same request → should be deduplicated and refunded once, not twice.
3. Invalid/Malformed Input
- Order ID belonging to a different user → must be rejected per-item with a 403 in the response, not fail the entire batch or silently skip it without telling the caller.
- Order ID that doesn't exist → per-item 404, batch should still process the valid remaining items.
- Order already shipped or already cancelled → reject with a specific status explaining why, don't attempt a double-refund.
4. State and Concurrency
- Same cancellation request submitted twice in rapid succession (double-click/retry) → must not issue two refunds for the same order (idempotency key required).
- Order gets shipped by the warehouse system in the few hundred milliseconds between validation and the cancellation transaction committing → must detect the state change and reject that specific item rather than cancelling a now-shipped order.
5. Integration Failure Points
- Payment refund API times out after inventory has already been restocked → must not leave the order in a state where inventory was returned but the customer wasn't refunded; needs compensating transaction or saga pattern.
- Notification service is down → cancellation and refund must still complete; notification failure should queue for retry, not roll back the whole operation.
- Inventory service returns a malformed response (missing SKU field) → must fail that item explicitly rather than assuming restock succeeded.
6. Silent Failure Risks
- Refund amount calculated using stale cached pricing data instead of the price actually paid → technically "succeeds" but refunds the wrong amount.
- Partial batch success returns HTTP 200 without clearly itemizing which orders failed → caller assumes everything succeeded when some didn't.
Top 5 Risks If Skipped
- Double refund on retry - direct financial loss, highest priority, very likely to occur in production given client-side retry logic.
- Refund/restock partial failure (no compensation) - creates permanently inconsistent state between payment and inventory systems.
- Race condition with warehouse shipping - customer receives a cancelled-but-shipped order, becomes a support and trust issue.
- Wrong refund amount from stale pricing - silent, hard to detect, directly costs money either to the business or the customer.
- Ambiguous partial-success response - causes downstream systems or the frontend to misreport order status to the customer.
بیشتر مهندسان موارد مرزی را به این دلیل نادیده نمی‌گیرند که بی‌دقت‌اند. آن‌ها این کار را می‌کنند چون یک تیکت ویژگی، مسیر خوشحال‌کننده (happy path) را در دو جمله توصیف می‌کند، و ذهن بقیه را با تصور اینکه ویژگی درست کار می‌کند، پر می‌کند. این پرامپت وجود دارد تا نقطه شروع متفاوتی را تحمیل کند: به‌جای پرسیدن «این باید چه کاری انجام دهد»، می‌پرسد «راه‌های خاصی که این می‌شکند چیست»، و این سؤال را به‌گونه‌ای ساختاردهی می‌کند که پاسخ واقعاً به‌عنوان یک برنامه تست قابل‌استفاده باشد، نه فهرست مبهمی از دغدغه‌ها.
چرا شش دسته به‌جای یک فهرست باز
یک پرامپت ساده «موارد مرزی این تابع را فهرست کن» معمولاً چند سناریوی بررسی null واضح تولید می‌کند و همان‌جا متوقف می‌شود، چون چیزی مدل را مجبور نمی‌کند به حالت‌های شکست سخت‌تر نگاه کند. تقسیم درخواست به مسیر خوشحال‌کننده، شرایط مرزی، ورودی نامعتبر، حالت/همزمانی، شکست یکپارچه‌سازی و ریسک‌های شکست خاموش کار می‌کند چون هر دسته یک ریشه متفاوت از باگ‌های تولید را هدف می‌گیرد. شرایط مرزی خطاهای off-by-one و نوع داده را می‌گیرد. همزمانی باگ‌هایی را می‌گیرد که فقط تحت ترافیک واقعی ظاهر می‌شوند، نه در یک تست دستی تک. نقاط شکست یکپارچه‌سازی این فرض را می‌گیرد که یک پایگاه‌داده یا API پرداخت همیشه پاسخ تمیز می‌دهد. ریسک‌های شکست خاموش -مواردی که کد بدون خطا اجرا می‌شود اما نتیجه نادرست تولید می‌کند- سخت‌ترین دسته برای فکرکردن بدون درخواست مستقیم است، و اغلب پرهزینه‌ترین برای کشف بعدی، که دقیقاً به همین دلیل پرامپت آن‌ها را به‌عنوان دسته‌ای مستقل برجسته می‌کند، نه اینکه اجازه دهد در «سایر» گم شوند.
چرا پرامپت ویژگی خاص می‌خواهد، نه توصیه عمومی
چک‌لیست‌های تست عمومی («ورودی‌های null را تست کن»، «رشته‌های خالی را تست کن») در هر کتاب درسی QA موجود است و ارزش کمی می‌افزاید. محدودیتی که «هر مورد باید مختص ویژگی واقعی توصیف‌شده باشد» دقیقاً همان چیزی است که این را از یک سخنرانی نظری تست به یک برنامه واقعی برای تابع پیش روی شما تبدیل می‌کند -این مدل را مجبور می‌کند درباره اینکه بازگرداندن موجودی، صدور بازپرداخت و ارسال اعلان دقیقاً چه کاری با هم انجام می‌دهند وقتی خارج از ترتیب یا به‌طور جزئی شکست می‌خورند استدلال کند، به‌جای فهرست‌کردن دسته‌های انتزاعی بدون محتوا.
چرا خروجی با یک فهرست ریسک رتبه‌بندی‌شده پایان می‌یابد، نه فقط یک ماتریس ساده
یک ماتریس تست ۲۰ تا ۳۰ موردی برای یک دور QA مفید است، اما هر مورد پیامد یکسانی ندارد، و یک مهندس شلوغ که با یک ضرب‌الاجل مواجه است باید بداند کدام ۳ تا ۵ مورد غیرقابل‌مذاکره‌اند حتی اگر باقی به یک تیکت پیگیری موکول شوند. پایان‌دادن با بخش «۵ ریسک برتر در صورت نادیده‌گرفتن»، هرکدام با یک دلیل یک‌جمله‌ای، یک فهرست فراگیر را به ابزار اولویت‌بندی تبدیل می‌کند -تفاوت میان سندی که هیچ‌کس پیش از انتشار نمی‌خوانَد و سندی که واقعاً تغییر می‌دهد چه چیزی اول ساخته می‌شود.
چه کسی باید از این استفاده کند، و چه زمانی
این پرامپت بیشترین ارزش خود را روی ویژگی‌هایی نشان می‌دهد که اشتباه‌گرفتن یک مورد مرزی پیامدهای واقعی دارد: هر چیزی که به پرداخت، موجودی، احراز هویت، یا داده‌ای که پس از واقعیت به‌سادگی قابل‌اصلاح نیست، مربوط می‌شود. آن را دقیقاً در نقطه‌ای که معمولاً شروع به نوشتن کد می‌کنید اجرا کنید، تیکت واقعی یا امضای تابع را به آن بدهید، و خروجی را به‌عنوان چک‌لیستی برای پیمایش -یا تحویل مستقیم به کسی که تست‌ها را می‌نویسد- در نظر بگیرید.