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

مقاييس العيوب (Defect Metrics) أرقام تُحسب من سجلات العيوب في أداة التتبع: كم عيباً اكتُشف، وأين، وما خطورته، وكم بقي مفتوحاً، وكم عاد بعد الإصلاح، وكم تسرّب إلى المستخدمين. ويذكر منهج ISTQB للمستوى التأسيسي مقاييس العيوب، مثل عدد العيوب المكتشفة والمُصلحة وكثافة العيوب ونسبة اكتشاف العيوب، ضمن المقاييس المستخدمة في متابعة الاختبار.

مثال بسيط: اكتشف المختبِرون ⁦48⁩ عيباً قبل الإصدار، وأبلغ المستخدمون عن ⁦12⁩ عيباً آخر في أول ⁦30⁩ يوماً. فنسبة اكتشاف العيوب هي ⁦48 ÷ 60 = 80%⁩: التقط الاختبار أربعة من كل خمسة عيوب عُرفت بعد شهر، وتسرّب ⁦20%⁩.

لماذا يهم

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

وهي تهمّ المختبِر مرتين. فأنت من ينتج البيانات الخام، لأن كل تقرير وكل درجة خطورة وكل تغيير في الحالة يغذّي هذه الأرقام، والسجلات المهملة تعطي مقاييس خاطئة. وكثيراً ما يُطلب منك تفسيرها: فعبارة «ارتفع معدل التسرّب لأن مزوّد الرسائل النصية الجديد اختُبر في بيئته التجريبية فقط» تفيد الفريق أكثر بكثير من «⁦20%⁩».

مقاييس العيوب الأساسية وصيغها

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

  • كثافة العيوب (Defect density) = العيوب ÷ حجم ناتج العمل، مثل ألف سطر من الشيفرة (KLOC) أو النقاط الوظيفية أو القصص. وهي تتيح مقارنة مناطق مختلفة الحجم: ⁦20⁩ عيباً في وحدة صغيرة قد تكون أسوأ من ⁦30⁩ في وحدة كبيرة.
  • نسبة اكتشاف العيوب (Defect Detection Percentage أو DDP) = العيوب التي اكتشفها الاختبار ÷ (ما اكتشفه الاختبار + ما اكتُشف بعده) × ⁦100⁩، مع نافذة متفق عليها لكلمة «بعده»، مثل أول ⁦30⁩ يوماً في الإنتاج. ويعرّفها مسرد ISTQB لمستوى اختبار بعينه، فيمكنك حسابها لاختبار النظام وحده أيضاً.
  • معدل التسرّب (Escape rate) = العيوب المكتشفة بعد ذلك ÷ الإجمالي نفسه، وهو مكمّل نسبة الاكتشاف. وبعض الفرق تسميه تسرّب العيوب (Defect leakage)، وبعضها يقسم على العيوب التي اكتشفها الاختبار بدلاً من الإجمالي، فتحقّق من الصيغة قبل أن تقارن.
  • عمر العيب (Defect age) = المدة من الإبلاغ حتى الإغلاق، أو حتى اليوم إن كان العيب مفتوحاً. اعرض الوسيط (Median، أي القيمة الوسطى بعد ترتيب الأعمار) وأقدم عيب في كل درجة خطورة، لا المتوسط وحده.
  • نسبة إعادة الفتح (Reopen rate) = العيوب المعاد فتحها ÷ العيوب المحلولة في الفترة نفسها. ويُعاد فتح العيب حين يُظهر اختبار التأكيد (Confirmation testing) أن الإصلاح لم ينجح، أو حين يعود الإخفاق.
  • التوزيع (Distribution) = تقسيم العيوب حسب سمة واحدة: الخطورة، أو المكوّن، أو مكان الاكتشاف، أو السبب الجذري. وهو يبيّن أين تتصرف، وهذا ما لا يبيّنه أي إجمالي.

جرّبها: حاسبة النسبة المئوية جرّبها: حاسبة الفرق بين التواريخ

مثال تطبيقي: إصدار من تطبيق لحجز مواعيد العيادات

بعد ⁦30⁩ يوماً من إطلاق الإصدار ⁦3.4⁩ من تطبيق لحجز مواعيد العيادات، يُعِدّ قائد الجودة (QA lead) للمراجعة الاستعادية (Retrospective). كان في أداة التتبع ⁦55⁩ تقريراً من الاختبار، منها ⁦4⁩ مكررة و⁦3⁩ رُفضت بوصفها «تعمل كما صُمّمت»، فبقي ⁦48⁩ عيباً صالحاً. وأبلغ المستخدمون والدعم الفني عن ⁦12⁩ عيباً آخر. يعرض المقطع أدناه البيانات بعد تنقيتها والنتائج، وهكذا يقرؤها قائد الجودة:

  • نسبة الاكتشاف ⁦80%⁩، وتبدو مقبولة، لكن أحد العيوب المتسرّبة حرج (Critical): كان بإمكان مريضين حجز الموعد نفسه (وأُصلح بإصلاح عاجل). والسؤال المفيد هو لماذا لم يكشف اختبار النظام الحجوزات المتزامنة، لا هل ⁦80%⁩ رقم جيد.
  • في مكوّن الحجز (Booking) أكبر عدد من العيوب (⁦27⁩)، لكن مكوّن الإشعارات (Notifications)، وهو شيفرة جديدة لتذكيرات الرسائل النصية، كثافته قرابة ضعف كثافة الحجز: ⁦8.4⁩ مقابل ⁦4.5⁩ لكل ألف سطر. وهو يستحق اهتماماً إضافياً في الإصدار القادم.
  • نسبة إعادة الفتح ⁦12%⁩، و⁦4⁩ من العيوب الستة المعاد فتحها في مكوّن المدفوعات (Payments)، وهذه علامة على أن الإصلاحات هناك تُؤكَّد على مسار واحد فقط، فيضيف الفريق عمليات الاسترداد إلى اختبارات التأكيد.
  • ⁦17⁩ عيباً من ⁦60⁩ تعود أسبابها إلى المتطلبات، وهذه حجة لمراجعة المتطلبات مبكراً لا لكتابة حالات اختبار أكثر.
  • ما زالت ⁦10⁩ عيوب مفتوحة، ليس بينها عيب حاجب (Blocker) أو حرج. متوسط عمرها ⁦16.6⁩ يوماً ووسيطها ⁦4.5⁩ يوم: معظمها جديد، وعيبان قديمان يرفعان المتوسط. والمهم هو عيب رئيسي (Major) مفتوح منذ ⁦60⁩ يوماً بانتظار مزوّد الرسائل النصية، وعيب تافه (Trivial) مفتوح منذ ⁦75⁩ يوماً يجب إصلاحه أو تأجيله بقرار صريح.
العيوب العشرة التي ما زالت مفتوحة بعد الإصدار ⁦3.4⁩ حسب الخطورة والعمر: سبعة منها عمرها أقل من أسبوع (الوسيط ⁦4.5⁩ يوم)، لكن عيباً رئيسياً ينتظر منذ ⁦60⁩ يوماً وعيباً تافهاً منذ ⁦75⁩ يوماً.
  • ⁦0–7⁩ أيام
  • ⁦8–30⁩ يوماً
  • أكثر من ⁦30⁩ يوماً
  • رئيسي (Major)مفتوحة: ⁦3⁩ · الأقدم: ⁦60⁩ يوماً
    • 2 ⁦0–7⁩ أيام
    • 0 ⁦8–30⁩ يوماً
    • 1 أكثر من ⁦30⁩ يوماً
  • ثانوي (Minor)مفتوحة: ⁦5⁩ · الأقدم: ⁦8⁩ أيام
    • 4 ⁦0–7⁩ أيام
    • 1 ⁦8–30⁩ يوماً
    • 0 أكثر من ⁦30⁩ يوماً
  • تافه (Trivial)مفتوحة: ⁦2⁩ · الأقدم: ⁦75⁩ يوماً
    • 1 ⁦0–7⁩ أيام
    • 0 ⁦8–30⁩ يوماً
    • 1 أكثر من ⁦30⁩ يوماً
  • كل العيوب المفتوحةمفتوحة: ⁦10⁩ · الوسيط: ⁦4.5⁩ يوم
    • 7 ⁦0–7⁩ أيام
    • 1 ⁦8–30⁩ يوماً
    • 2 أكثر من ⁦30⁩ يوماً

العمر = عدد الأيام منذ الإبلاغ عن العيب. لا يوجد عيب حاجب (Blocker) أو حرج (Critical) مفتوح. والمتوسط ⁦16.6⁩ يوماً يرتفع بسبب العيبين القديمين لكنه لا يسمّيهما.

Release 3.4, clinic booking app: tracker export 30 days after go-live

Found before release   55 reports - 4 duplicates - 3 rejected = 48 defects
Found in production    first 30 days                         = 12 defects
                       (1 Critical, 3 Major, 8 Minor)

DDP           48 / (48 + 12)            = 80%
Escape rate   12 / 60                   = 20%
Reopen rate   6 reopened / 50 resolved  = 12%   (4 of the 6 in Payments)

Component       Defects   Changed KLOC   Density
Booking              27            6.0   4.5 per KLOC
Payments             12            3.0   4.0 per KLOC
Notifications        21            2.5   8.4 per KLOC

Root cause (60)     requirements 17 | code 31 | environment 8 | data 4

Open defects (10)   Major 3 | Minor 5 | Trivial 2   (no Blocker or Critical)
Age in days         Major 1, 4, 60 | Minor 2, 2, 3, 6, 8 | Trivial 5, 75
                    mean 16.6 | median 4.5

اقرأ مقاييس العيوب بحذر

قبل أن تقارن رقمين، تحقّق من أنهما حُسبا بالطريقة نفسها، واسأل ما الذي قد يفسّرهما غير ما يبدو.

  • قواعد ثابتة: التعريف نفسه للعيب الصالح، والسلّم نفسه للخطورة والتصنيف (ومعيار IEEE 1044 مخطط قياسي لتصنيف حالات الشذوذ في البرمجيات)، والنافذة نفسها. فمعدل التسرّب المقيس بعد ⁦7⁩ أيام لا يُقارن بمعدل مقيس بعد ⁦90⁩ يوماً.
  • الأعداد بجانب النسب: الأعداد الصغيرة تتأرجح بشدة. عيبان متسرّبان من ⁦10⁩ يعنيان ⁦20%⁩، وعيب واحد إضافي يجعلها ⁦3⁩ من ⁦11⁩، أي ⁦27%⁩.
  • الاتجاهات لا اللقطات: قارن المكوّن أو الفريق بإصداراته السابقة، لا بمنتج آخر.
  • السياق: قلة العيوب قد تعني شيفرة جيدة أو اختباراً قليلاً، والكثافة العالية قد تعني شيفرة ضعيفة أو اختباراً دقيقاً. وكما يقول المبدأ الأول من مبادئ الاختبار: الاختبار يُظهر وجود العيوب لا غيابها.
  • القراءة بالأزواج: اقرأ نسبة الاكتشاف مع خطورة ما تسرّب، وعمر العيب مع الخطورة، والكثافة مع مقدار الاختبار الذي ناله ذلك الجزء.

كيف يُساء استخدام مقاييس العيوب

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

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

أخطاء شائعة

  • عدّ التقارير المكررة والمرفوضة، فيكبر الإجمالي مع الضجيج في أداة التتبع.
  • عرض نسبة دون أعدادها ونافذتها: «معدل التسرّب ⁦20%⁩» من كم عيباً، وخلال أي فترة؟
  • عرض متوسط عمر العيب وحده، فيبقى أقدم عيب رئيسي أو حرج مخفياً.
  • اعتبار قلة العيوب دليلاً على الجودة دون السؤال عن مقدار ما اختُبر.
  • مقارنة كثافة العيوب بين فرق أو منتجات تقيس الحجم والخطورة بطرق مختلفة.

من منظور ضمان الجودة

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

وحين تعرض المقاييس في فرز العيوب أو مراجعة الإصدار أو المراجعة الاستعادية، أحضر الأعداد والاتجاه وجملة تفسير واحدة، واختم بمقترح: «⁦4⁩ من ⁦6⁩ عيوب معاد فتحها في المدفوعات؛ هل نضيف عمليات الاسترداد إلى اختبارات التأكيد؟». واسأل أي قرار يدعمه الرقم، ولا تستخدمه لترتيب الأفراد.

تمرين عملي

احسب مقاييس العيوب لسبرنت واقرأها

المطلوب

أطلق متجر إلكتروني سبرنت (Sprint) مدته أسبوعان قبل ⁦14⁩ يوماً. البيانات أدناه منقّاة مسبقاً: لا مكررات ولا تقارير مرفوضة. وكلمة production تعني أن المستخدمين أبلغوا عن العيب بعد الإطلاق. والعمر (Age) هو عدد الأيام من الإبلاغ حتى الإغلاق، أو حتى اليوم إن كان العيب ما زال مفتوحاً.

احسب المقاييس، ثم اكتب ملخصاً من ثلاث جمل للمراجعة الاستعادية للسبرنت.

المادة
Changed in the sprint (KLOC): Checkout 1.5 | Search 2.0 | Profile 1.0

ID     Severity  Component  Found in    Status  Age  Reopened  Root cause
SP-01  Major     Search     testing     Closed    3  no        code
SP-02  Minor     Search     testing     Closed    2  yes       code
SP-03  Critical  Checkout   testing     Closed    1  no        requirements
SP-04  Major     Checkout   testing     Closed    5  yes       requirements
SP-05  Minor     Profile    testing     Closed    2  no        code
SP-06  Minor     Checkout   testing     Open      4  no        requirements
SP-07  Trivial   Profile    testing     Open     26  no        code
SP-08  Major     Checkout   testing     Closed    6  yes       code
SP-09  Minor     Search     testing     Open      9  no        environment
SP-10  Major     Checkout   production  Open      3  no        requirements
SP-11  Minor     Profile    production  Closed    2  no        code
SP-12  Major     Checkout   production  Open     12  no        requirements
الخطوات
  1. احسب نسبة اكتشاف العيوب (DDP) ومعدل التسرّب.
  2. احسب نسبة إعادة الفتح للعيوب المغلقة.
  3. احسب متوسط عمر العيوب المفتوحة ووسيطه، وسمِّ أقدم عيب مفتوح في كل درجة خطورة.
  4. احسب الكثافة لكل مكوّن، وحدّد ما يلفت النظر في التوزيع حسب السبب الجذري.
  5. اكتب الملخص مع ذكر الأعداد بجانب كل نسبة ومقترح واحد.
إظهار الإجابة النموذجية
الإجابة النموذجية

نسبة الاكتشاف: اكتشف الاختبار ⁦9⁩ عيوب واكتُشف ⁦3⁩ في الإنتاج، فنسبة الاكتشاف ⁦9 ÷ 12 = 75%⁩ ومعدل التسرّب ⁦3 ÷ 12 = 25%⁩. واثنان من العيوب الثلاثة المتسرّبة رئيسيان، وكلاهما في Checkout.

نسبة إعادة الفتح: ⁦7⁩ عيوب مغلقة، أُعيد فتح ⁦3⁩ منها (⁦SP-02⁩ و⁦SP-04⁩ و⁦SP-08⁩): ⁦3 ÷ 7 ≈ 43%⁩، واثنان منها في Checkout.

العيوب المفتوحة: ⁦SP-10⁩ (⁦3⁩ أيام)، و⁦SP-06⁩ (⁦4⁩)، و⁦SP-09⁩ (⁦9⁩)، و⁦SP-12⁩ (⁦12⁩)، و⁦SP-07⁩ (⁦26⁩). المتوسط ⁦54 ÷ 5 = 10.8⁩ يوم، والوسيط ⁦9⁩ أيام. الأقدم في كل درجة خطورة: الرئيسي ⁦SP-12⁩ (⁦12⁩ يوماً، وهو عيب إنتاج)، والثانوي (Minor) ⁦SP-09⁩ (⁦9⁩ أيام)، والتافه ⁦SP-07⁩ (⁦26⁩ يوماً).

الكثافة: Checkout ⁦6 ÷ 1.5 = 4.0⁩ لكل ألف سطر، وSearch ⁦3 ÷ 2.0 = 1.5⁩، وProfile ⁦3 ÷ 1.0 = 3.0⁩. السبب الجذري: المتطلبات ⁦5⁩، والشيفرة ⁦6⁩، والبيئة ⁦1⁩، وعيوب المتطلبات الخمسة كلها في Checkout.

ملخص ممكن: «اكتشف الاختبار ⁦9⁩ من ⁦12⁩ عيباً معروفاً (نسبة الاكتشاف ⁦75%⁩)، والعيبان الرئيسيان المتسرّبان كلاهما في Checkout ويعودان إلى المتطلبات. وفي Checkout أعلى كثافة (⁦4.0⁩ لكل ألف سطر) وكل عيوب المتطلبات الخمسة و⁦2⁩ من ⁦3⁩ عيوب معاد فتحها، لذا نقترح مراجعة معايير القبول فيه مع مالك المنتج قبل السبرنت القادم. ويحتاج ⁦SP-12⁩، وهو عيب إنتاج رئيسي مفتوح منذ ⁦12⁩ يوماً، إلى مالك اليوم». ومع ⁦12⁩ عيباً فقط يحرّك كل عيب النسبة بنحو ⁦8⁩ نقاط، ولهذا تُذكر الأعداد.

أسئلة شائعة

ما النسبة الجيدة لاكتشاف العيوب؟

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

لماذا أعرض وسيط عمر العيب بدلاً من المتوسط؟

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

هل تُستخدم مقاييس العيوب لتقييم المختبِرين أو المطورين؟

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

من أين تأتي بيانات مقاييس العيوب؟

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

المراجع

  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
  • ISTQB GlossaryISTQBالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
  • Certified Tester Advanced Level Test Management (CTAL-TM) v3.0ISTQB · 2024منهج ISTQB المتقدم لإدارة الاختبار: التخطيط والتقدير، والاختبار المبني على المخاطر، والمتابعة، والمقاييس والتقارير.
  • IEEE 1044-2009 — IEEE Standard Classification for Software AnomaliesIEEE Standards Association · 2009مفردات وسمات قياسية لتصنيف شذوذات البرمجيات — العيوب والإخفاقات وأثرها (مدرج لدى IEEE كمعيار غير نشط محفوظ).

تدرّب بأدوات متقن

حساب النسب المئوية ونسبة التغيّر والزيادة/النقصان وكم تمثّل X من Y بالنسبة المئوية.

أدوات مساعدة

احسب الفرق الدقيق بين تاريخين بالسنوات والأشهر والأيام والساعات والوحدات الإجمالية.

أدوات مساعدة

للتعمّق أكثر

تقدّمك في هذا الموضوع

جزء من مسار تعلم ضمان الجودة