Prompt عملي لتحويل مواصفات Feature إلى Test Plan حقيقية
Why this prompt matters
Teams often ship features with happy-path coverage but miss edge cases around validation, state, permissions, retries, and billing or data integrity. A structured prompt like this shortens QA planning time and catches expensive bugs before they reach customers.
What we use it for
Use this when a team has finished a feature spec or a pull request is nearly ready, and you need a strong first-pass test plan before QA, code review, or release sign-off.
Prompt
Role: Act as a senior software test engineer and QA architect. Context: I will give you a feature description, user story, acceptance criteria, technical notes, and optionally code snippets or API contracts. Your job is to turn that into a practical test plan that a development team can use immediately. Task: Generate a comprehensive test package for this feature. Include functional test scenarios, edge cases, negative tests, validation rules, API-level checks if relevant, state transition checks, permission and authentication checks if relevant, regression risks, and a prioritized list of tests to automate first. Constraints: - Do not repeat the input back to me. - Be specific and concrete. - Flag missing requirements or ambiguities before listing tests. - Separate tests by level: unit, integration, end-to-end, and exploratory. - For each important test, include: purpose, preconditions, steps, expected result, and priority. - Include boundary conditions, invalid inputs, empty states, loading states, partial failure cases, concurrency/race-condition risks, and rollback or retry behavior where relevant. - If the feature touches data, include data integrity checks. - If the feature touches APIs, include status code and error response coverage. - If the feature touches UI, include validation, accessibility, and cross-device considerations. - Keep the output actionable for a real engineering team. Output Format: 1. Feature Summary (2-3 bullets) 2. Missing Requirements / Ambiguities 3. Key Risks 4. Test Matrix Table with columns: Test Level | Scenario | What to Verify | Priority 5. Detailed High-Priority Test Cases 6. Automation Recommendations 7. Regression Checklist Feature to analyze: [PASTE FEATURE DESCRIPTION HERE] Acceptance criteria: [PASTE ACCEPTANCE CRITERIA HERE] Technical notes / code / API contract: [PASTE TECHNICAL DETAILS HERE]
Result
Feature Summary - Users can schedule a subscription pause from the account billing page for 1 to 12 weeks. - The system must stop future charges during the pause window without canceling the subscription. - Users should see the pause dates immediately in the UI and receive a confirmation email.
Missing Requirements / Ambiguities - It is unclear whether a user can edit an existing pause window after saving it. - The spec does not say what happens if the next billing date falls on the same day the pause starts. - There is no explicit rule for overlapping pause requests made from mobile and web at nearly the same time.
Key Risks - Billing logic may continue charging active invoices already queued before the pause job runs. - UI state may show the pause as saved before the billing service confirms it. - Time-zone conversion could shift the effective pause start date for users outside UTC.
Test Matrix Unit | Validate pause duration boundaries | 1 week and 12 weeks accepted, 0 and 13 rejected | High Unit | Date normalization | Stored pause dates remain correct across time zones | High Integration | Billing service sync | Scheduled charges are skipped inside pause window | High Integration | Email confirmation | Confirmation email is triggered once after successful save | Medium End-to-end | Create pause from billing page | User can save pause dates and see updated status immediately | High End-to-end | Invalid overlapping request | Second overlapping pause request returns clear validation error | High Exploratory | Refresh and resume flows | UI remains consistent after page refresh, logout, and relogin | Medium
Detailed High-Priority Test Case Test: Prevent invalid pause durations Purpose: Ensure business rules reject unsupported pause lengths. Preconditions: User has an active monthly subscription and access to billing settings. Steps: Open the pause modal, select a 0-week duration, submit, then try 13 weeks, then try 1 week and 12 weeks. Expected result: 0 and 13 weeks are blocked with a validation message; 1 and 12 weeks save successfully. Priority: High
Automation Recommendations - Automate billing skip logic first because it has direct revenue impact. - Add API contract tests for pause creation, overlap rejection, and idempotent retries. - Add one cross-time-zone end-to-end test covering UTC and a non-UTC locale.
Regression Checklist - Subscription resume date is correct after the pause ends. - Existing invoices are not duplicated or silently canceled. - Account status, email notifications, and billing history remain consistent across web and mobile surfaces.
Generated Image
الفرق الجيدة لا تفوّت غالباً happy path. ما يفوتها هو المناطق الأصعب مثل validation وretry وتغيّر state والصلاحيات وحالات الفشل الجزئي. من هذه النقاط عادةً تتسرّب الأخطاء إلى production، خصوصاً عندما ينتقل Feature بسرعة من المواصفات إلى التنفيذ.
هذا Prompt صُمم لهذه الفجوة بالضبط. بدلاً من أن تطلب من نموذج AI فقط "اكتب بعض الاختبارات"، فهو يحدد الدور كما لو كنت تتعامل مع QA engineer كبير. هذا الهيكل يجبر النموذج أولاً على كشف نقص المتطلبات والغموض، ثم تقسيم التغطية بين unit وintegration وend-to-end وexploratory بحيث يكون الناتج مفيداً فعلاً للمطورين والمختبرين.
أهم قرار في تصميم هذا Prompt هو الدقة. كل Test Case عالي الأولوية يجب أن يتضمن purpose وpreconditions وsteps وexpected result وpriority. هذا يجعل الناتج أقرب إلى عمل يمكن لفريق هندسي حقيقي أن يؤتمته ويراجعه ويتابعه. كما يقلل من المشكلة الشائعة حيث ينتج AI نقاطاً عامة تبدو جيدة لكنها لا تصمد أمام codebase حقيقي.
هذا Prompt مفيد بشكل خاص للـ Features التي تمس المال أو صلاحيات المستخدم أو الـ API أو حالة الواجهة. في هذه الحالات، قد يتحول boundary check مفقود أو bug صامت في retry بسرعة إلى مشكلة دعم. وعندما تطلب الصياغة بشكل صريح invalid inputs وempty states ومخاطر concurrency وسلوك rollback، فإنها تدفع النموذج نحو تحليل الفشل بدلاً من التلخيص السطحي.
النتيجة ليست بديلاً عن حكم QA. لكنها طريقة سريعة لإنتاج مسودة أولى صارمة، وكشف الغموض في المواصفات، وتحديد ما يجب أتمتته قبل الإصدار.