كيف تكتب خطة اختبار (Test Plan)

لماذا توجد خطة الاختبار

تجيب الخطة عن الأسئلة التي يطرحها أصحاب المصلحة قبل الاختبار وأثناءه: ماذا نختبر بالضبط، وما الذي لا نختبره عمداً، ومتى سنعرف ما يكفي للإصدار، وماذا تحتاجون منّا، وما الذي قد يوقفكم. وإذا كانت هذه الإجابات في رأس قائد الجودة فقط، فالخطة غير موجودة مهما قالت الوثيقة.

المخطط الكلاسيكي مأخوذ من IEEE 829، وأقسام خطته (عناصر الاختبار، والميزات المشمولة وغير المشمولة، والمنهج، ومعايير النجاح والفشل، والتعليق والاستئناف، والمخرجات، والبيئة، والمسؤوليات، والجدول، والمخاطر، والاعتمادات) ما زالت واضحة في معظم النماذج. وقد حلّت سلسلة ISO/IEC/IEEE 29119 محل IEEE 829-2008، وجزؤها الثالث ISO/IEC/IEEE 29119-3 هو اليوم المرجع الدولي لتوثيق الاختبار، ويعدّ استراتيجية الاختبار المختارة للمشروع جزءاً من خطة الاختبار. ويصف منهج ISTQB CTFL v4.0 المحتوى المعتاد لخطة الاختبار بعبارات مشابهة: سياق الاختبار، والافتراضات والقيود، وأصحاب المصلحة، والتواصل، وسجل المخاطر، ومنهج الاختبار، والميزانية والجدول.

الخطة وثيقة حيّة. تُكتب قبل بدء تصميم الاختبارات، وتُراجَع مع التطوير والمنتج والعمليات، وتُعتمد، ثم تُحدَّث كلما تغيّر النطاق أو المواعيد أو المخاطر — برقم إصدار حتى يعرف الجميع أيّ نسخة يقرؤون.

ما الذي تحتويه خطة الاختبار

• النطاق — الإصدار أو المشروع، وعناصر الاختبار (Test items) من بناءات وخدمات وتطبيقات وإصدارات، وحدود النظام قيد الاختبار.
• أهداف الاختبار — ما يجب أن تكتشفه هذه الجولة أو تثبته، مثل «لا عيب حرج في المدفوعات» أو «التحقق من كل معيار قبول في الإصدار 4.0».
• الميزات المشمولة بالاختبار — مسرودة بمعرّف المتطلب أو القصة مع مستوى الخطر، حتى يظهر عمق الاختبار لكل ميزة.
• الميزات غير المشمولة — مع السبب (لم تتغير، أو خارج الإصدار، أو يملكها ويختبرها مورّد). وهذا القسم يمنع أغلى أنواع سوء الفهم.
• المنهج — مستويات الاختبار وأنواعه، وتقنيات التصميم لكل ميزة، وما يُؤتمت وأين يعمل، ونطاق الانحدار (Regression)، والاختبار غير الوظيفي، وأيّ انحراف عن الاستراتيجية مع تبريره.
• معايير الدخول والخروج والتعليق والاستئناف — انظر القسم التالي.
• البيئات — أيّ البيئات والإصدارات والتكاملات وبيئات التجربة (Sandbox) والأجهزة والمتصفحات، ومن يوفّر الوصول.
• بيانات الاختبار — مصدرها (مصطنعة ومولّدة)، وأحجامها، وكيف تُعاد تهيئتها، وقيود الخصوصية.
• الجدول والمعالم — أنشطة الاختبار بتواريخها واعتمادها على معالم التطوير والتصميم والعمليات.
• الموارد والأدوار والمسؤوليات — من يصمّم، ومن ينفّذ، ومن يؤتمت، ومن يفرز العيوب، ومن يرفع التقارير، ومن يعتمد؛ ونسب التخصيص وأيّ تدريب لازم.
• المخاطر وخطط التخفيف — مخاطر المشروع على الاختبار نفسه (تأخر البناءات، وعدم استقرار البيئات، ونقص المهارات)، لكلٍّ منها مالك. أما مخاطر المنتج فمكانها تحليل المخاطر الذي يحدد عمق الاختبار.
• الافتراضات والاعتماديات — ما تسلّم به الخطة، وما يحتاجه الاختبار من الفرق الأخرى ومتى.
• المخرجات — حالات الاختبار، والاختبارات المؤتمتة، وتقارير الحالة، وتقارير العيوب، وتقرير إنجاز الاختبار.
• الاعتمادات — من يعتمد الخطة، ومن يتخذ قرار الإصدار بشكل منفصل.

جرّبها: المتطلبات ← حالات اختبار جرّبها: محلّل تغطية الاختبار بالذكاء الاصطناعي

معايير الدخول والخروج والتعليق والاستئناف

تحوّل المعايير الجدل إلى فحوص. فمعايير الدخول (Entry criteria) تحدد متى يجوز بدء نشاط الاختبار، ومعايير الخروج (Exit criteria) تحدد متى يُعدّ مكتملاً. ومعايير التعليق (Suspension criteria) تحدد متى يجب إيقاف الاختبار مؤقتاً لأن الاستمرار يهدر الجهد، ومعايير الاستئناف (Resumption criteria) تحدد ما يجب إصلاحه قبل العودة. ويشرح دليل ضمان الجودة الشامل كيف تعمل معايير الدخول والخروج بوابات للإصدار؛ ومهمة الخطة أن تجعلها محددة وقابلة للقياس في نطاقها.

• الدخول — البناء منشور في بيئة الاختبار، واختبار الدخان (Smoke) ناجح، ومعايير القبول مراجَعة، وبيانات الاختبار محمّلة، والتكاملات المطلوبة متاحة.
• الخروج — الاختبارات المخططة منفّذة (مثلاً كل اختبارات الخطر العالي ونسبة معلنة من الباقي على الأقل)، ولا عيوب حاجبة أو حرجة مفتوحة، والعيوب المتبقية مقبولة من مالك المنتج، وحزمة الانحدار ناجحة، والأهداف غير الوظيفية متحققة.
• التعليق — فشل اختبار الدخان على بناء جديد، أو تعطّل بيئة أساسية أو بيئة التجربة أكثر من مدة متفق عليها، أو عيب واحد يحجب نسبة كبيرة من الاختبارات المخططة.
• الاستئناف — بناء مُصلَح ينجح في اختبار الدخان، أو استعادة البيئة، أو التحقق من إصلاح العيب الحاجب.
• اكتب كل معيار بحيث يصل شخصان إلى الإجابة نفسها بنعم أو لا؛ فعبارة «مختبَر بشكل كافٍ» ليست معياراً.

ترتيب الأولويات والجدول والموارد

رتّب عمل الاختبار حسب الخطر أولاً: الميزات الأعلى احتمالاً للفشل والأشد أثراً تُصمَّم اختباراتها وتُنفَّذ أولاً، حتى إذا نفد الوقت كان ما بقي دون اختبار هو الأقل خطراً. وضمن هذا الترتيب احترم الاعتماديات — لا يمكن اختبار ميزة قبل وجود بنائها وبياناتها — وقدّم اختبار كل ما قد يفرض إعادة تصميم، كالتكامل مع مزوّدي الدفع أو الهوية. والترتيب المبني على التغطية أو على المتطلبات قاعدتان ثانويتان مفيدتان.

ابنِ الجدول بالعكس بدءاً من قرار الإصدار. اترك وقتاً صريحاً لإصلاح العيوب وإعادة الاختبار، ولجولة الانحدار الأخيرة، وللاختبارات غير الوظيفية التي تحتاج إلى بناء مستقر. وتخطيط الموارد أكثر من عدد الأشخاص: سجّل من يملك المعرفة بالمجال والوصول إلى الأجهزة ومهارات الأتمتة التي يحتاجها كل نشاط، وما الذي يحدث عند غيابه. أما أرقام الجهد نفسها فتأتي من التقدير، الذي يغطيه دليل تقدير الاختبار.

• جدوِل الاختبار الأخطر والأكثر اعتماداً على غيره أولاً، لا الأسهل.
• خطّط لدورة إصلاح وإعادة اختبار واحدة على الأقل؛ فالخطط التي تخلو منها تفترض أنه لن تكون هناك عيوب.
• احتفظ ببديل مسمّى لكل مهارة حرجة: مجال المدفوعات، والأجهزة المحمولة، وأدوات الأداء.
• اربط المعالم بالأحداث لا بالتواريخ فقط: «تبدأ الدورة 1 عند تحقق معايير الدخول»، مع التاريخ المستهدف بجانبها.

جرّبها: مولّد الاختبار المبني على المخاطر جرّبها: مولّد الاختبار المبني على المخاطر بالذكاء الاصطناعي

نموذج خطة اختبار

انسخ المخطط أدناه واحذف ما لا يحتاجه سياقك. والقسم الذي يبقى فارغاً يجب أن يذكر السبب («لا اختبار أداء: لا تغيير في الخادم في هذا الإصدار») بدلاً من أن يختفي، لأن الغياب قرار.

TEST PLAN - <product> <release or project>        ID: TP-<nnn>   Version: <x.y>
Status: Draft | In review | Approved     Owner: <QA lead>      Date: <yyyy-mm-dd>
Strategy reference: <link to test strategy and its version>

1.  Introduction and context
    Purpose, release summary, links to requirements, designs and the risk register
2.  Scope
    2.1 Test items                builds, services, apps, platforms and versions under test
    2.2 Features to be tested     <ID> <feature> - risk level - depth of testing
    2.3 Features not to be tested <feature> - reason
3.  Test objectives               what this round of testing must find or show
4.  Approach
    Levels and types; design techniques per feature; automation (what runs where);
    regression scope; non-functional testing; deviations from the strategy and why
5.  Criteria
    5.1 Entry   5.2 Exit   5.3 Suspension   5.4 Resumption
6.  Test environments             environments, versions, sandboxes, devices, browsers, access
7.  Test data                     sources (synthetic), volumes, reset procedure, privacy rules
8.  Schedule and milestones       activities, target dates, dependencies
9.  Resources and responsibilities  roles, people, allocation, backups, training needs
10. Estimates                     effort ranges and the assumptions behind them
11. Risks and mitigations         project risk - likelihood/impact - mitigation - owner
12. Assumptions and constraints
13. Dependencies                  what testing needs from whom, by when
14. Deliverables                  test cases, automated tests, status reports,
                                  defect reports, test completion report
15. Communication and reporting   cadence, channel, audience, escalation path
16. Approvals                     name - role - decision - date

جرّبها: مولّد خطة الاختبار جرّبها: مولّد قوائم تحقق QA بالذكاء الاصطناعي

خطة اختبار خفيفة للفرق الرشيقة

في Scrum والأطر المشابهة تقع القرارات طويلة الأمد في الاستراتيجية وفي تعريف الإنجاز (Definition of Done)، ويعيش جزء كبير من الخطة في قائمة المهام (Backlog): تحمل كل قصة معايير قبولها، ويخطط الفريق مهام الاختبار في تخطيط السبرنت. وما يستحق الكتابة لكل سبرنت أو إصدار قصير: الهدف، وما هو مشمول ومستبعد، وأهم المخاطر وكيف تُختبر، وما يعمل من انحدار، وعلامَ تعتمد البيئة والبيانات، وأيّ إضافات إلى تعريف الإنجاز. صفحة واحدة في ويكي الفريق مرتبطة بلوحة السبرنت تكفي.

SPRINT TEST PLAN - Bustan Market, sprint 42 (fictional)      one page, team wiki

Goal:      Customers can pay with Apple Pay on iOS and web; saved-card flow unchanged
In scope:  BUS-812 Apple Pay (iOS app, Safari), BUS-815 order confirmation email (ar/en)
Out:       Android wallet payments (planned for sprint 44), seller portal
Top risks: R1 payment captured but order not created (L4 x I5)
              -> idempotency and retry tests at API level, automated in CI
           R2 Arabic email totals misaligned (L3 x I3) -> RTL rendering check
Approach:  API tests for the new payment endpoint; one exploratory session per story;
           regression = automated checkout suite + manual saved-card check on 2 devices
Env/data:  staging + payment provider sandbox; synthetic customers only
DoD adds:  acceptance criteria pass; 0 open Blocker/Critical; regression green; demo done
Who:       Sara (QA, iOS), Omar (QA, web/API); developers own unit and API tests
If blocked: sandbox outage -> use mocked gateway responses; raise in daily stand-up

مثال تطبيقي: مقتطف من خطة اختبار إصدار

على سبيل المثال، المقتطف أدناه من خطة الإصدار 4.0 لـ«بستان ماركت»، السوق السعودي الخيالي المستخدم في دليل استراتيجية الاختبار. ويُظهر الأقسام التي يتركها الناس غامضة غالباً: الميزات مع خطرها وعمقها، والميزات غير المختبرة مع أسبابها، ومعايير قابلة للقياس، وجدولاً فيه دورة إصلاح وإعادة اختبار، ومخاطر مشروع لها مالكون.

• معايير الدخول في المثال: نشر ⁦4.0.0-rc⁩ في بيئة staging، ونجاح اختبار الدخان، ومراجعة معايير القبول، وإتاحة بيئة التجربة للدفع، وتحميل مجموعة البيانات المصطنعة v7.
• معايير الخروج: تنفيذ كل اختبارات الخطر العالي ونجاحها (أو إعفاء مكتوب منها يصدره مالك المنتج)، وتنفيذ 95% على الأقل من كل الاختبارات المخططة، وعدم وجود أي عيب حاجب أو حرج مفتوح، وثلاثة عيوب رئيسية (Major) مفتوحة على الأكثر لكلٍّ منها موعد إصلاح، ونجاح الانحدار ليلتين متتاليتين، وزمن p95 لواجهة API الخاصة بإتمام الشراء أقل من 800 ms عند ثلاثة أضعاف ذروة الحمل المعتادة.
• معايير التعليق: فشل اختبار الدخان على بناء جديد، أو تعطّل بيئة التجربة أكثر من 4 ساعات عمل، أو عيب واحد يحجب أكثر من 30% من الاختبارات المخططة.
• معايير الاستئناف: بناء مُصلَح ينجح في اختبار الدخان، أو استعادة بيئة التجربة، أو التحقق من إصلاح العيب الحاجب — فلكل سبب تعليق شرط عودة يقابله.

TEST PLAN TP-040 - Bustan Market 4.0 "One-page checkout" (fictional excerpt)  v1.1

2.2 Features to be tested                                   Risk    Depth
    CHK-01 One-page checkout, web + apps (ar/en)            High    boundaries, negative,
                                                                    exploratory, auto regression
    CHK-02 Coupon and promotion stacking rules              High    decision table (14 rules),
                                                                    automated API tests
    CHK-03 Cash-on-delivery limit (max 2,000 SAR)           Medium  1,999.99 / 2,000.00 / 2,000.01
    CHK-04 Delivery slot picker (Hijri/Gregorian display)   Medium  both calendars, ar/en, RTL
    CHK-05 Order confirmation SMS and email                 Low     content check ar/en, one pass

2.3 Features not to be tested
    Seller portal - unchanged in 4.0; covered by the nightly regression suite only
    Courier tracking internals - partner-owned; our webhook handling IS in scope

5.  Criteria
    Entry:   4.0.0-rc deployed to staging; smoke green; acceptance criteria reviewed;
             payment sandbox reachable; synthetic data set v7 loaded
    Exit:    all High-risk tests executed and passed (or waived in writing by the PO);
             >= 95% of all planned tests executed; 0 open Blocker/Critical;
             <= 3 open Major defects, each with a fix date; regression green two nights
             running; p95 checkout API < 800 ms at 3x normal peak
    Suspend: smoke fails on a new build; sandbox down > 4 working hours;
             > 30% of planned tests blocked by one defect
    Resume:  fixed build passes smoke; sandbox restored; blocking defect verified

8.  Schedule (working days)
    D1-D3   design + data setup        D4-D11  execution, cycle 1 (High risk first)
    D12-D13 fix verification + full regression    D14 load test    D15 go/no-go

11. Project risks                         Mitigation                          Owner
    Payment sandbox instability           mocked gateway for negative paths   QA lead
    Late delivery of CHK-02 promotions    API-level tests first, UI last      Dev lead
    One tester on leave D8-D10            developer pairs on regression runs  Eng. manager

جرّبها: مولّد سيناريوهات الانحدار

أخطاء شائعة في خطط الاختبار

• خطة تعيد صياغة الاستراتيجية ولا تقول شيئاً عن هذا الإصدار.
• غياب قسم «الميزات غير المشمولة» — فيفترض كل شخص أن ميزته مغطّاة.
• معايير خروج لا يمكن قياسها («تغطية كافية»، «بناء مستقر»).
• لا وقت للإصلاح وإعادة الاختبار، أو جدول ينتهي في يوم الإصدار دون هامش لقرار الإطلاق.
• خلط مخاطر المنتج (ما قد يفشل للمستخدمين) بمخاطر المشروع (ما قد يوقف الاختبار) في قائمة واحدة غير مميَّزة.
• كتابتها مرة واحدة للاعتماد وعدم تحديثها أبداً؛ فتصف في منتصف الإصدار مشروعاً آخر.
• اعتمادات من أشخاص لم يقرؤوها — راجع النطاق والمعايير والمخاطر معهم في اجتماع بدلاً من ذلك.

الأسئلة الشائعة

المراجع

• ISO/IEC/IEEE 29119-3:2021 — Software and systems engineering — Software testing — Part 3: Test documentationISO/IEC/IEEE · 2021نماذج ومحتوى وثائق الاختبار — سياسة الاختبار واستراتيجيته وخطته وتقارير الحالة والإنجاز وتقارير الحوادث.
• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• Certified Tester Advanced Level Test Management (CTAL-TM) v3.0ISTQB · 2024منهج ISTQB المتقدم لإدارة الاختبار: التخطيط والتقدير، والاختبار المبني على المخاطر، والمتابعة، والمقاييس والتقارير.
• ISO/IEC/IEEE 29119-2:2021 — Software and systems engineering — Software testing — Part 2: Test processesISO/IEC/IEEE · 2021نموذج عمليات الاختبار: العمليات المؤسسية وعمليات إدارة الاختبار وعمليات الاختبار الديناميكي، مع أنشطتها ومخرجاتها.
• Agile Testing: A Practical Guide for Testers and Agile Teams (Lisa Crispin, Janet Gregory)Addison-Wesley (Pearson) · 2009أرباع الاختبار الرشيق وكيف يعمل المختبرون داخل فريق التسليم — أساس «الاختبار في الطبقة الصحيحة».
• The 2020 Scrum GuideKen Schwaber and Jeff Sutherland · 2020تعريف Scrum: مسؤولياته وأحداثه ومخرجاته، بما فيها تعريف الإنجاز (Definition of Done) الذي يساعد الاختبار على تحقيقه.