الخطأ والعيب والإخفاق والسبب الجذري

لماذا يهم

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

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

من الخطأ إلى العيب إلى الإخفاق

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

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

• الخطأ (Mistake): سوء فهم متطلب، أو كتابة > بدلاً من >=، أو نسيان حالة.
• العيب (Fault / Bug): يمكن اكتشافه بالمراجعة دون تشغيل أي شيء.
• الإخفاق: لا يمكن ملاحظته إلا أثناء تشغيل النظام.
• بعض الفرق تقول «Bug» للعيب وللإخفاق معاً، و«Error» لرسالة في السجل. في التقارير، حدّد أيّهما تقصد.

عيوب بلا إخفاقات، وإخفاقات بلا عيوب

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

والأخطاء والعيوب ليست السبب الوحيد للإخفاقات. يذكر المنهج الظروف البيئية، مثل الإشعاع أو المجالات الكهرومغناطيسية التي تؤثر في البرامج الثابتة (Firmware). أما في الاختبار اليومي فالأسباب الواقعة خارج الشيفرة التي تختبرها أبسط من ذلك: خادم اختبار متوقف، أو بيئة تجريبية لطرف ثالث تتجاوز مهلة الاستجابة، أو شهادة منتهية الصلاحية. وبعضها يعود إلى خطأ بشري في مكان آخر — فالقيمة الخاطئة في إعدادات النشر عيب في ذلك الملف — لكن المسؤول عنه وطريقة إصلاحه مختلفان.

• في ظروف محددة فقط: حساب تاريخ لا يتعطل إلا يوم ⁦29⁩ فبراير.
• عيب كامن: عيب تقريب في عملة لم يفعّلها المتجر بعد.
• عيب محجوب (Masked): عيب في الخطوة ⁦3⁩ من الدفع لا يمكن أن يظهر ما دام عيب آخر يُفشل الخطوة ⁦2⁩ في كل مرة. ويسمي مسرد ISTQB ذلك حجب العيوب (Defect masking).
• البيئة: إرسال نموذج يعيد 503 Service Unavailable بينما يُعاد نشر خدمة البريد الإلكتروني في بيئة الاختبار.

جرّبها: محلّل رسائل الأخطاء بالذكاء الاصطناعي

السبب الجذري: لماذا وقع الخطأ

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

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

الإيجابية الكاذبة والسلبية الكاذبة

والاختبارات قد تخطئ أيضاً. يسمي مسرد ISTQB نتيجة الاختبار التي تبلّغ عن عيب غير موجود إيجابية كاذبة (False positive)، والنتيجة التي لا تكشف عيباً موجوداً فعلاً سلبية كاذبة (False negative). و«إيجابية» هنا تعني «قال الاختبار إن هناك مشكلة». ويسميهما المسرد أيضاً نتيجة فشل كاذب (False-fail result) ونتيجة نجاح كاذب (False-pass result).

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

جرّبها: مقارنة النصوص (Diff) جرّبها: مقارنة JSON

مثال تطبيقي: اسم عربي مرفوض عند التسجيل

المتطلب R-07: «يقبل حقل الاسم الكامل الحروف العربية والإنجليزية والمسافات، من ⁦2⁩ إلى ⁦60⁩ حرفاً». تسجّل مختبِرة باسم Sara Alqahtani فيُنشأ الحساب. وبالاسم نفسه مكتوباً بالحروف العربية يردّ النموذج: «Name contains invalid characters». هذا هو الإخفاق.

تبلّغ المختبِرة عن المدخلات والنتيجة المتوقعة والنتيجة الفعلية، ويجد المطور بالتنقيح (Debugging) العيب المبيّن أدناه. وحين أعاد أحد الإرسالات أثناء الجلسة 503 Service Unavailable، أعادت تشغيل الاختبار بعد تعافي البيئة وأبلغت المسؤول عن البيئة بدلاً من الإبلاغ عن عيب في التسجيل.

• العيب: النمط لا يقبل إلا الحروف اللاتينية والمسافات.
• الخطأ: نسخه المطور من نموذج قديم للنشرة البريدية يدعم الإنجليزية فقط دون الرجوع إلى R-07.
• السبب الجذري: معايير القبول وبيانات الاختبار المشتركة لم تتضمن إلا أسماء إنجليزية.
• سلبية كاذبة ظهرت في الطريق: اختبار API كان يرسل اسماً عربياً منذ أسابيع، لكنه لا يتحقق إلا من رمز الحالة 200، بينما كان جسم الاستجابة يقول invalid_name.
• بعد الإصلاح: اختبار التأكيد (Confirmation testing) بالاسمين، وإضافة أمثلة عربية إلى معايير القبول وبيانات الاختبار.

// signup/validate.js
const NAME_PATTERN = /^[A-Za-z ]{2,60}$/;  // Latin letters and spaces only

NAME_PATTERN.test('Sara Alqahtani');  // true  -> account created
NAME_PATTERN.test('سارة القحطاني');   // false -> "Name contains invalid characters"

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

أسئلة شائعة

المراجع

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• ISTQB GlossaryISTQBالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.