مقاييس الاختبار التي تقود القرارات

ابدأ من القرار لا من لوحة المعلومات

تتناول مناهج ISTQB المقاييس كجزء من متابعة الاختبار والتحكم فيه (Test monitoring and control): تقيس التقدم والجودة مقابل الخطة لتصحّح المسار. وطريقة عملية لاختيار المقاييس هي نهج الهدف–السؤال–المقياس (Goal–Question–Metric): اكتب الهدف (إصدار صفحة الدفع دون عيب دفع معروف)، ثم الأسئلة التي تخبرك هل تقترب منه (أي مخاطر الدفع لم تُختبر بعد؟ هل تُصلَح العيوب بسرعة اكتشافها؟)، وبعدها فقط المقاييس التي تجيب عن هذه الأسئلة.

• لكل مقياس مالك، وتعريف مكتوب (ما الذي يُحسب وما لا يُحسب ومن أي نظام)، وقرار يغذّيه.
• فضّل الاتجاهات على اللقطات: نسبة نجاح 82% لا تقول الكثير؛ أما 64% ← 75% ← 82% خلال ثلاثة أيام فتقول الكثير.
• اقرن كل مقياس بمقياس مقابل بحيث يظهر تحسين أحدهما بالغش في الآخر (الاختبارات المنفَّذة مع العيوب المتسرّبة؛ السرعة مع نسبة فشل التغييرات).
• أبقِ المجموعة صغيرة. خمسة مقاييس يقرؤها الناس أفضل من ثلاثين لا يقرؤها أحد.

مقاييس التغطية

تجيب التغطية (Coverage) عن سؤال: «كم مما يهمّ قد مارسناه؟» والسؤال المفيد دائماً هو: تغطية ماذا؟ المتطلبات أم المخاطر أم الشيفرة. لكلٍّ منها مالك مختلف ونقطة عمياء مختلفة.

• تغطية المتطلبات / معايير القبول = المعايير التي لها اختبار ناجح واحد على الأقل ÷ إجمالي المعايير. فرّق بين «له اختبار» و«له اختبار ناجح»؛ فالثاني وحده له معنى عند الإصدار. وتحتاج إلى التتبّعية (Traceability): ربط كل اختبار بالمعيار الذي يتحقق منه.
• تغطية المخاطر = المخاطر المحددة التي نُفّذت اختباراتها المخططة ونجحت ÷ المخاطر المحددة، مع عرضها حسب مستوى الخطر. عبارة «المخاطر التسعة العالية جداً مغطاة، و4 من 12 متوسطة لم تُغطَّ بعد» حوار إصدار؛ أما «85% من الاختبارات نجحت» فليست كذلك.
• تغطية الشيفرة (Code coverage) — تغطية التعليمات (الأسطر) أو الفروع التي تقيسها أداة أثناء تشغيل الاختبارات. مفيدة لإيجاد شيفرة لا يلمسها أي اختبار. لكنها لا تُظهر أن الاختبارات تتحقق من شيء: اختبار بلا تحقق (Assertion) قد ينفّذ كل سطر. التغطية العالية للأسطر لا تثبت جودة الاختبارات؛ أما التغطية المنخفضة في وحدة حرجة فتثبت وجود فجوة.
• فحص قوة الاختبارات — حين تُستخدم تغطية الشيفرة مؤشراً للجودة، فإن مراجعة التحققات أو استخدام اختبار الطفرات (Mutation testing) — أي تغيير الشيفرة عمداً والتأكد من فشل اختبار ما — يُظهر هل الشيفرة المغطاة يُتحقق منها فعلاً.

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

مقاييس التنفيذ

تُظهر مقاييس التنفيذ موقع جهد الاختبار مقابل الخطة. اعرضها حسب مستوى الخطر أو منطقة الميزة لا كإجمالي واحد فقط، لأن نسبة تنفيذ 90% قد تخفي أن الـ 10% غير المختبَرة هي مسار الدفع.

• المخطَّط مقابل المنفَّذ مقابل الناجح — الصورة الأساسية للتقدم. المنفَّذ = الناجح + الفاشل؛ والاختبارات المحجوبة وغير المشغَّلة تُعرض منفصلة.
• نسبة النجاح (Pass rate) = الناجح ÷ المنفَّذ. راقب اتجاهها عبر البناءات؛ فانخفاضها في أواخر الدورة يعني غالباً انحدارات سببتها الإصلاحات.
• الاختبارات المحجوبة (Blocked) — اختبارات لا يمكن تشغيلها بسبب مشكلة في البيئة أو البيانات أو اعتمادية. هي إشارة خطر مشروع وتحتاج إلى مالك وموعد، لا مجرد عدد.
• إعادة التشغيل والنتائج المتذبذبة (Flaky) — إذا نجح اختبار عند إعادة المحاولة فقط فاحسبه منفصلاً. نسبة النجاح التي تشمل اختبارات متذبذبة أعيد تشغيلها تبالغ في تقدير الاستقرار.
• صحة الحزمة المؤتمتة — مدة حزمة الانحدار في CI ونسبة التقلب فيها، لأن الحزمة البطيئة أو غير الموثوقة يتوقف الناس عن تشغيلها.

مقاييس العيوب

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

• كثافة العيوب (Defect density) = العيوب ÷ الحجم (لكل ألف سطر شيفرة، أو لكل نقطة وظيفية، أو لكل قصة). تحفّظات: مقاييس الحجم تختلف بين اللغات والفرق، ومزيج الخطورة أهم من العدد، والكثافة العالية قد تعني اختباراً جيداً بقدر ما تعني شيفرة سيئة. قارن المكوّن بتاريخه هو لا بفرق أخرى.
• نسبة اكتشاف العيوب (DDP) = العيوب المكتشفة قبل الإصدار ÷ (المكتشفة قبل الإصدار + المكتشفة بعده خلال نافذة متفق عليها) × 100. على سبيل المثال، 45 عيباً في الاختبار و5 أُبلغ عنها في أول 30 يوماً بعد الإصدار تعطي DDP = 45 ÷ 50 = 90%.
• معدل التسرّب (Escape rate / Defect leakage) = المكمّل: 5 ÷ 50 = 10% تسرّبت. ويمكن تتبّع التسرّب حسب المرحلة أيضاً — عيوب أفلتت من اختبار النظام واكتُشفت في اختبار القبول.
• عمر العيب (Defect age) — الزمن من الإبلاغ حتى الإغلاق (أو حتى التحقق من الإصلاح). اعرض الوسيط وأقدم العيوب المفتوحة حسب الخطورة؛ فالمتوسطات تشوّهها عيوب قليلة قديمة جداً.
• نسبة إعادة الفتح (Reopen rate) = العيوب المعاد فتحها ÷ العيوب المحلولة في الفترة. على سبيل المثال، 6 من 80 = 7.5%. ارتفاعها يشير إلى إصلاحات ناقصة أو تقارير غير واضحة أو إعادة اختبار ضعيفة.
• العيوب حسب الخطورة — المفتوحة والمكتشفة لكل درجة خطورة عبر الزمن؛ وسؤال الإصدار عادةً: «كم عيباً حاجباً وحرجاً مفتوحاً؟»، والجواب يجب أن يكون صفراً أو مقبولاً صراحة.
• العيوب حسب السبب الجذري — المتطلبات، والتصميم، والشيفرة، والإعدادات، والبيانات، والبيئة. هذا هو المقياس الذي يحسّن العملية: إذا كان ثلث العيوب يعود إلى متطلبات غير واضحة، فمزيد من الاختبار لن يصلحه؛ بل مراجعات المتطلبات.

مقاييس التدفق والتسليم: مقاييس DORA

تصف DORA (DevOps Research and Assessment) أداء تسليم البرمجيات بخمسة مقاييس تجمّعها في محورين: الإنتاجية (Throughput) وتضم زمن تنفيذ التغيير وتكرار النشر وزمن التعافي من النشر الفاشل، وعدم الاستقرار (Instability) ويضم نسبة فشل التغييرات ونسبة إعادة العمل في النشر؛ وقد تطوّر هذا النموذج من المقاييس الأربعة الأصلية. هي تقيس منظومة التسليم ككل لا فريق الاختبار، لكن الاختبار يؤثر فيها بقوة: الاختبارات المؤتمتة السريعة والموثوقة تجعل النشر المتكرر آمناً، وضعف الاختبارات يظهر في صورة عمليات نشر فاشلة.

• زمن تنفيذ التغيير (Change lead time) — الزمن الذي يستغرقه التغيير من إيداعه في نظام التحكم بالإصدارات حتى نشره في الإنتاج.
• تكرار النشر (Deployment frequency) — عدد مرات نشر التغييرات إلى الإنتاج.
• زمن التعافي من النشر الفاشل (Failed deployment recovery time) — المدة اللازمة للتعافي من نشر فاشل يتطلب تدخلاً فورياً.
• نسبة فشل التغييرات (Change fail rate) — نسبة عمليات النشر التي تتطلب تدخلاً فورياً بعدها، مثل التراجع (Rollback) أو إصلاح عاجل (Hotfix).
• نسبة إعادة العمل في النشر (Deployment rework rate) — نسبة عمليات النشر غير المخطط لها التي تُجرى بسبب حادث في الإنتاج. اقرأ التعريفات في موقع DORA قبل اعتماد أيٍّ منها، ولا تستعر أرقاماً مرجعية من مصادر أخرى؛ قارن اتجاهك أنت.
• من منظور الاختبار: نسبة فشل التغييرات هي النظير على مستوى التسليم لمعدل تسرّب العيوب؛ ومدة حزمة الاختبار جزء كبير من زمن تنفيذ التغيير.

التقارير ولوحات المعلومات

يغطي نوعان من التقارير معظم الاحتياجات. يسميهما منهج CTFL تقرير تقدم الاختبار (Test progress report) الذي يصدر بانتظام أثناء الاختبار، وتقرير إتمام الاختبار (Test completion report) الذي يصدر عند انتهاء مستوى اختبار أو تكرار أو إصدار؛ ويوثّق المعيار ISO/IEC/IEEE 29119-3 تقرير أثناء العمل باسم تقرير حالة الاختبار (Test status report). يقول تقرير التقدم أين يقف الاختبار مقابل الخطة، وما المحجوب، وما الذي يحتاج إلى قرار. ويلخّص تقرير الإتمام ما اختُبر، والانحرافات عن الخطة، وجودة المنتج، والمخاطر المتبقية، والدروس المستفادة.

لوحة معلومات واحدة لا تناسب كل قارئ. ابنِ عروضاً لكل جمهور واحتفظ بالتعريفات نفسها في جميعها.

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

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

نموذج تقرير حالة اختبار من صفحة واحدة

التقرير أدناه لإصدار خيالي (Checkout v2، الإصدار 5.3) في اليوم السابع من عشرة، وحالته العامة «كهرماني» (AMBER): النطاق يسير وفق الخطة لكن خطرين يحتاجان إلى قرار. جدول التقدم مقسّم حسب مستوى الخطر: نُفّذت كل اختبارات الخطر العالي جداً الـ 46، نجح منها 44 وفشل 2؛ ونُفّذ 31 من 38 اختباراً عالي الخطر (نجح 29 وفشل 2)، مع 4 محجوبة و3 لم تُشغَّل؛ ونُفّذ 30 فقط من 64 اختباراً متوسط أو منخفض الخطر. والمنفَّذ هو الناجح مع الفاشل، ويُعرض المحجوب وغير المشغَّل منفصلين.

معدل النجاح هو الناجح مقسوماً على المنفَّذ، أي 103 من 107 أو نحو 96%، ولا يدخل فيه المحجوب ولا غير المشغَّل، واستُبعدت منه إعادات تشغيل الاختبارات المتذبذبة (اختباران في الحجر). وتغطية معايير القبول باختبار ناجح 71 من 84 (85%) بعد 62% في اليوم الخامس، وهذا هو الاتجاه. والعيوب المفتوحة: صفر حاجب، وعيب حرج واحد هو CHK-231 (طلب مكرر عند إعادة المحاولة في بوابة الدفع، والإصلاح قيد المراجعة)، و3 رئيسية و6 ثانوية. والاختبارات الأربعة المحجوبة تخص ⁦3-D Secure⁩ بسبب تعطّل بيئة التجربة (Sandbox) لدى الجهة المصدرة، ولها مالك وموعد متوقع. ويختم التقرير بقرارين مطلوبين: قبول تغطية جزئية للأجهزة في R5 أو تمديد الاختبار يوماً، وهل يُطلق الإصدار وCHK-214 ما زال مفتوحاً مع تفعيل تنبيه على طول الطابور.

TEST STATUS REPORT — Checkout v2 · Release 5.3 · Day 7 of 10 · data as of 24 Sep 2026 17:00
Overall: AMBER — scope on track; two risks need a decision

Progress by risk     Planned  Executed  Passed  Failed  Blocked  Not run
Very high                 46        46      44       2        0        0
High                      38        31      29       2        4        3
Medium / Low              64        30      30       0        0       34
Total                    148       107     103       4        4       37

Acceptance criteria with a passing test: 71 of 84 (85%)   day 5: 62%
Pass rate (passed / executed): 96%   flaky re-runs excluded: 2 tests quarantined

Defects open: Blocker 0 · Critical 1 · Major 3 · Minor 6
  CHK-231 Critical — duplicate order created on gateway retry (fix in review)
This period: 5 new · 7 closed · 1 reopened

Blocked: 4 tests on 3-D Secure — issuer sandbox down since 22 Sep (owner: DevOps, ETA 25 Sep)
Risks: R5 device coverage 2 of 4; R6 email delay (CHK-214) open

Decisions needed:
  1. Accept partial device coverage for R5, or extend testing by one day
  2. Release with CHK-214 open and a queue-length alert in place?
Next: finish High-risk tests, retest CHK-231, full regression run on day 9

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

حدود مقاييس الاختبار وسوء استخدامها

المقاييس تغيّر السلوك. فحين يصبح الرقم هدفاً يُحكم على الناس به، يحسّن الناس الرقم، ويتوقف عن قياس ما وُضع لقياسه — وهي الفكرة المعروفة عادة بقانون غودهارت (Goodhart’s law). ويكون الضرر أشدّ حين تُستخدم المقاييس لترتيب الأفراد أو لمقارنة فرق تعمل على منتجات مختلفة.

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

ما الذي تقيسه بدلاً من ذلك

• بدلاً من عدد حالات الاختبار ← تغطية المتطلبات والمخاطر باختبارات ناجحة، حسب مستوى الخطر.
• بدلاً من الأخطاء لكل مختبِر ← معدل تسرّب العيوب والعيوب حسب السبب الجذري للفريق ككل.
• بدلاً من نسبة النجاح وحدها ← نسبة النجاح مع المنفَّذ مقابل المخطط، والاختبارات المحجوبة، والاتجاه.
• بدلاً من هدف لتغطية الشيفرة ← قائمة بالشيفرة غير المغطاة في الوحدات عالية الخطر، مع مراجعة التحققات أو اختبار الطفرات فيها.
• بدلاً من نسبة الأتمتة ← حصة مخاطر الانحدار المغطاة بفحوص مؤتمتة، ومدة الحزمة، ونسبة التقلب.
• بدلاً من العيوب المصلحة لكل مطوّر ← عمر العيب ونسبة إعادة الفتح حسب المكوّن.
• بدلاً من جداول ترتيب الفرق ← اتجاه كل فريق الخاص، يُناقش في اجتماع المراجعة الاستعادية (Retrospective).

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

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

المراجع

• Certified Tester Advanced Level Test Management (CTAL-TM) v3.0ISTQB · 2024منهج ISTQB المتقدم لإدارة الاختبار: التخطيط والتقدير، والاختبار المبني على المخاطر، والمتابعة، والمقاييس والتقارير.
• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• ISO/IEC/IEEE 29119-3:2021 — Software and systems engineering — Software testing — Part 3: Test documentationISO/IEC/IEEE · 2021نماذج ومحتوى وثائق الاختبار — سياسة الاختبار واستراتيجيته وخطته وتقارير الحالة والإنجاز وتقارير الحوادث.
• DORA's software delivery performance metricsDORA (Google Cloud)مقاييس DORA للتسليم — زمن تنفيذ التغيير وتكرار النشر وزمن التعافي من النشر الفاشل ونسبة فشل التغييرات وما يتصل بها — مجمّعة حسب الإنتاجية وعدم الاستقرار.
• ISTQB GlossaryISTQBالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.