استراتيجية الاختبار: دليل عملي

استراتيجية الاختبار مقابل خطة الاختبار ومنهج الاختبار

تُستعمل المصطلحات الثلاثة بتساهل في الممارسة، لذا يفيد تثبيتها. استراتيجية الاختبار وصف طويل الأمد لكيفية إجراء الاختبار عبر مؤسسة أو برنامج أو خط منتجات. وخطة الاختبار وثيقة على مستوى المشروع أو الإصدار تقول ما الذي سيُختبر هذه المرة، وكيف، ومن يختبره، ومتى، وبأيّ موارد، ووفق أيّ معايير. ومنهج الاختبار (Test approach) هو الطريقة التي تُطبَّق بها الاستراتيجية في مشروع محدد: المزيج المختار من التقنيات والمستويات والأنواع ومعايير الدخول والخروج المسجّل في الخطة.

يفصل المعيار ISO/IEC/IEEE 29119-3، وهو جزء توثيق الاختبار في سلسلة 29119، بين وثائق المستوى المؤسسي ووثائق مستوى المشروع. ففي المستوى المؤسسي تقع سياسة الاختبار (Test policy) — لماذا تختبر المؤسسة وماذا تنتظر من الاختبار — وممارسات الاختبار الدائمة للمؤسسة، التي سمّتها طبعة 2013 استراتيجية الاختبار المؤسسية. وفي مستوى المشروع تكون الوثيقة المركزية هي خطة الاختبار، والخطة نفسها تسجّل استراتيجية الاختبار المختارة لذلك المشروع. ويستعمل منهج ISTQB التأسيسي مصطلح «منهج الاختبار» للاختيارات نفسها على مستوى المشروع. وأيّاً كانت الأسماء في مؤسستك، أبقِ المستويين منفصلين: مجموعة قواعد نادراً ما تتغير، وخطة لكل إصدار تطبّقها.

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

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

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

• النطاق — المنتجات والمنصات والمكوّنات والواجهات التي تغطيها الاستراتيجية، وما لا تغطيه صراحةً (مثل أنظمة الأطراف الثالثة التي تُختبر عند حدّ التكامل فقط).
• أهداف الاختبار — ما يجب أن يحققه الاختبار: اكتشاف العيوب مبكراً في المناطق عالية الخطورة، وتقديم دليل لقرار الإصدار، وحماية المسارات الخاضعة للتنظيم، وضبط كلفة اختبار الانحدار.
• خصائص الجودة — أيّ خصائص ISO/IEC 25010 تهمّ هذا المنتج وبأيّ عمق تُختبر: الملاءمة الوظيفية، وكفاءة الأداء، والتوافق، وقابلية التفاعل، والموثوقية، والأمان، وقابلية الصيانة، والمرونة، والسلامة.
• مستويات الاختبار وأنواعه — الوحدة، والتكامل/API، والنظام، والقبول؛ والوظيفي، والانحدار (Regression)، والاستكشافي، والأداء، والأمان، وإتاحة الوصول، والتوطين؛ ومن يملك كلاً منها.
• منهج المخاطر — كيف تُحدَّد مخاطر المنتج وتُقيَّم وتُستعمل لتحديد عمق الاختبار وترتيبه (يغطيه بعمق دليل الاختبار المبني على المخاطر).
• منهج تصميم الاختبار — التقنيات المتوقعة لكل نوع من المتطلبات: تقسيم التكافؤ والقيم الحدّية للمدخلات، وجداول القرار لقواعد العمل، وانتقالات الحالة لمسارات العمل، وجلسات استكشافية للميزات الجديدة.
• البيئات وبيانات الاختبار — ما البيئات الموجودة، ومدى قربها من الإنتاج، وكيف تُعزل الخدمات الخارجية أو تُحاكى، وكيف تُنشأ بيانات الاختبار (مصطنعة، ولا تُنسخ بيانات شخصية أبداً).
• استراتيجية الأتمتة — ما الذي يُؤتمت وعلى أيّ مستوى، وأين يعمل في CI/CD، ومن يصونه، ومتى يُحذف الاختبار.
• الأدوات — إدارة الاختبار، وتتبّع العيوب، وأطر الأتمتة، وCI، والتقارير؛ تُذكر بالفئة، وبالمنتج حين يكون مستقراً.
• معايير الدخول والخروج — الشروط الافتراضية لبدء كل مستوى وإنهائه، التي تستطيع الخطط تشديدها لا إضعافها بصمت.
• المقاييس والتقارير — القياسات القليلة المستعملة في القرارات، وكم مرة تُرفع ولمن.
• الأدوار والمسؤوليات — قائد الجودة، والمختبرون، والمطورون، ومالك المنتج، وDevOps، والأمان؛ ومن يعتمد الإصدار.
• إدارة العيوب — مقياسا الخطورة والأولوية والمسار من الإبلاغ حتى الإغلاق.

أنواع مناهج الاختبار

تجمع أدبيات الاختبار مناهج الاختبار عادةً في عدد قليل من الفئات. وقد سردتها مناهج ISTQB التأسيسية السابقة صراحةً (مثل طبعة 2018)، أما منهج CTFL v4.0 الحالي فيناقش منهج الاختبار ضمن تخطيط الاختبار لا كقائمة مسمّاة. وتبقى الفئات مفردات مفيدة، لأن كل استراتيجية حقيقية تقريباً مزيج مقصود منها.

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

كيف تختار المناهج وتدمجها

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

اختر بالنظر إلى السياق لا إلى التفضيلات. وتؤكد مدرسة الاختبار المعتمدة على السياق (Context-driven) هذه النقطة بقوة: الممارسة جيدة أو سيئة فقط بالنسبة إلى المنتج والأشخاص والقيود التي أمامك.

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

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

من الاستراتيجية إلى التنفيذ: التخطيط والمخاطر والتقدير والمقاييس

تتحول الاستراتيجية إلى عمل عبر أربعة أنشطة، لكلٍّ منها دليله في هذا الموضوع. خطة الاختبار تطبّق الاستراتيجية على إصدار: النطاق، والعناصر، والميزات المشمولة وغير المشمولة، والمنهج، والمعايير، والبيئات، والجدول، والأشخاص، والمخاطر، والمخرجات. والاختبار المبني على المخاطر (Risk-based testing) هو النواة التحليلية لمعظم الاستراتيجيات: تحديد مخاطر المنتج، وتقييمها بالاحتمال والأثر، وتحويل الدرجات إلى عمق للاختبار وترتيب له. وتقدير الاختبار (Test estimation) يحوّل النطاق المخطط إلى جهد ووقت بنطاقات وافتراضات معلنة بدلاً من رقم واحد متفائل. ومقاييس الاختبار (Test metrics) تغلق الحلقة: التغطية واتجاهات العيوب والعيوب المتسرّبة وصحة الحِزم تخبرك هل تعمل الاستراتيجية وأين تغيّرها.

التتبّع (Traceability) يربط الأربعة. فحين يرتبط كل متطلب أو معيار قبول باختبارات، وترتبط كل نتيجة اختبار به، تستطيع الخطة إظهار ما هو مغطّى، ويستطيع تحليل المخاطر إظهار العناصر عالية الخطورة التي لم تُختبر بعد، وتصبح للمقاييس دلالة. أبقِ مصفوفة المتطلبات إلى الاختبارات حيّة منذ السبرنت الأول بدلاً من إعادة بنائها قبل التدقيق.

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

مثال: مخطط استراتيجية لمنتج تجارة إلكترونية سعودي

على سبيل المثال، لنأخذ «بستان ماركت»، وهو سوق إلكتروني خيالي يبيع لعملاء في السعودية عبر موقع ثنائي اللغة (عربي/إنجليزي) وتطبيقي iOS وAndroid، مع الدفع بالبطاقة ومدى وApple Pay والدفع عند الاستلام. المخطط أدناه من نوع الاستراتيجية التي يستطيع قائد الجودة كتابتها له في صفحتين. وكل رقم فيه مثال مختار للمنتج الخيالي، لا توصية لمنتجك.

TEST STRATEGY - Bustan Market (fictional example)          v1.2 - owner: QA lead

Scope
  In:  web storefront (ar/en), iOS and Android apps, seller portal, public API v2,
       checkout and payments (card, mada, Apple Pay, cash on delivery), order tracking
  Out: courier partner systems (tested at our integration boundary only),
       ERP internals (owned by finance IT)

Objectives
  - No known Blocker/Critical defect in checkout, payment or refund at release
  - Every acceptance criterion traced to at least one executed test
  - Core journeys covered by automated regression that runs on every merge

Quality characteristics (ISO/IEC 25010) and depth
  Functional suitability   high    requirements-based + risk-based design
  Security                 high    OWASP ASVS baseline; external pen test before major releases
  Performance efficiency   high    p95 checkout API < 800 ms at 3x normal peak (sale days)
  Interaction capability   medium  Arabic RTL, accessibility checks on core journeys
  Compatibility            medium  top browsers/devices from analytics, reviewed quarterly
  Reliability              medium  payment gateway timeouts, retries, idempotent orders

Test levels and owners
  Unit (developers, CI) - API/integration (developers + QA, CI) - system/E2E (QA)
  - acceptance (product owner + QA) - post-deploy checks (DevOps + QA)

Risk approach
  Product risk register per release; likelihood x impact on 1-5 scales;
  score >= 15: boundary, negative, exploratory and automated regression coverage

Test design
  Partitions and boundaries for amounts, quantities, coupons; decision tables for
  promotion rules; state transitions for order status; exploratory session per feature

Environments and data
  Staging mirrors production versions; payment provider sandbox; synthetic data only
  (Arabic/English names, +9665 mobile numbers, SA IBAN format); no production copies

Automation
  API regression on every merge; 25-30 E2E journeys nightly and pre-release;
  mobile smoke on real devices before store submission

Entry / exit (defaults)
  Entry: build deployed, smoke green, acceptance criteria reviewed
  Exit:  planned tests executed; 0 open Blocker/Critical; Major defects have an agreed
         plan; regression green; performance target met

Metrics and reporting
  Daily status in the squad channel; release report with requirement coverage, open
  defects by severity, escaped defects from the previous release, suite duration, flaky rate

Roles
  QA lead (owns strategy), squad testers, developers (unit/API tests), product owner
  (acceptance, impact scores), DevOps (environments), security lead (pen test scope)

Review: quarterly, and after any Critical production incident

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

كيف تكتب استراتيجية الاختبار وتحافظ عليها

• 1. اجمع المدخلات: سياسة الاختبار إن وُجدت، وبنية المنتج، والالتزامات التنظيمية والتعاقدية، وحوادث الإنتاج والعيوب المتسرّبة خلال العام الماضي، ومهارات الفريق.
• 2. قرّر أيّ خصائص الجودة تهمّ وبأيّ عمق؛ واكتب ذلك في جدول قصير لتظهر المفاضلات.
• 3. اختر مزيج المناهج لكل منطقة من المنتج واذكر السبب في جملة واحدة لكلٍّ منها.
• 4. عرّف المستويات والأنواع والملكية بحيث لا يكون أيّ نشاط ملكاً لـ«الجميع» وبالتالي لا أحد.
• 5. ضع معايير الدخول والخروج الافتراضية، ومقياسَي العيوب، والمقاييس القليلة التي ستُرفع.
• 6. راجع المسودة مع قادة التطوير والمنتج وDevOps والأمان؛ فالاستراتيجية التي لم يقرأها المطورون لن تُتّبع.
• 7. انشرها حيث تشير إليها الخطط، وراجعها بإيقاع ثابت وبعد الحوادث الجسيمة — فالعيب الحرج المتسرّب دليل على أن قراراً ما في الاستراتيجية كان خاطئاً.

أخطاء شائعة

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

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

المراجع

• ISO/IEC/IEEE 29119-3:2021 — Software and systems engineering — Software testing — Part 3: Test documentationISO/IEC/IEEE · 2021نماذج ومحتوى وثائق الاختبار — سياسة الاختبار واستراتيجيته وخطته وتقارير الحالة والإنجاز وتقارير الحوادث.
• ISO/IEC/IEEE 29119-2:2021 — Software and systems engineering — Software testing — Part 2: Test processesISO/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 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelISO/IEC · 2023نموذج جودة المنتج: الملاءمة الوظيفية وكفاءة الأداء والتوافق وقابلية التفاعل والموثوقية والأمان وقابلية الصيانة والمرونة.
• ISO/IEC/IEEE 29119-1:2022 — Software and systems engineering — Software testing — Part 1: General conceptsISO/IEC/IEEE · 2022المعيار الدولي لاختبار البرمجيات: المفاهيم والعمليات والتوثيق والتقنيات.
• Agile Testing: A Practical Guide for Testers and Agile Teams (Lisa Crispin, Janet Gregory)Addison-Wesley (Pearson) · 2009أرباع الاختبار الرشيق وكيف يعمل المختبرون داخل فريق التسليم — أساس «الاختبار في الطبقة الصحيحة».
• Lessons Learned in Software Testing: A Context-Driven Approach (Cem Kaner, James Bach, Bret Pettichord)Wiley · 2001دروس عملية في الإبلاغ عن الأخطاء وتصميم الاختبارات والأتمتة وإدارة الاختبار — مدرسة الاختبار المدفوع بالسياق.