أنواع المشاكل في البرمجيات - Error, Bug, Defect, Failure - شرح أكثر

مقدمة

كم مرة سمعت أحد يتحدث "في bug بالنظام" أو "لقينا defect جديد" أو "صار failure بالسيرفر"؟

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

في هذا الدرس، سنتحدث عن أربع مصطلحات أساسية:

• Error (الخطأ)
• Defect (العيب)
• Bug (الخلل)
• Failure (الفشل)

الأهداف التعليمية

بنهاية هذا الدرس، ستكون قادراً على:

• التفريق بين Error و Defect و Bug و Failure
• فهم الدورة الكاملة لكيف ينتقل الخطأ من المبرمج للمستخدم النهائي
• تطبيق التعريفات الواقعية على أمثلة حقيقية
• فهم ليش تعريفاتنا العملية أفضل من تعريفات ISTQB التقليدية

Error (الخطأ) - الخطأ البشري

Error هو خطأ بشري (Human Mistake) يحصل أثناء كتابة الكود.

متى يحصل الـ Error؟

الـ Error يحصل عندما:

• المبرمج يفهم المتطلبات غلط
• المبرمج يكتب الكود غلط (حتى لو فهم المتطلبات صح)
• المبرمج ينسى شرط من شروط الـ Business Logic
• المبرمج يستخدم operator غلط (مثلاً > بدل >=)

مثال واقعي: نظام القبول الجامعي

تخيل معي إنه عندنا نظام للقبول في كلية الطب. شروط القبول هي:

• معدل الثانوية العامة 94% فما فوق
• العمر أقل من أو يساوي 30 سنة

المبرمج كتب الكود التالي:

public boolean isEligibleForMedicalSchool(int average, int age) {
  if (average > 94 && age < 30) {// هنا في خطأ!
    return true;
  } else {
    return false;
  }
}

ما الخطأ هون؟

المبرمج كتب:

• average > 94 ← لكن المفروض average >= 94
• age < 30 ← لكن المفروض age <= 30

هذا Error - خطأ بشري من المبرمج!

Defect (العيب) - المشكلة أثناء الاختبار

Defect هو نفس الخطأ (Error) لكن عندما ننكشفه أثناء الاختبار (Testing) - يعني قبل أن يوصل للـ Production.

متى نسمي المشكلة Defect؟

عندما:

• المختبر يلاقي المشكلة في بيئة Testing أو Staging
• المشكلة موجودة لكن ما وصلت بعد للعملاء
• القصة لسه تحت التطوير أو في مرحلة QA

في هذه الحالة، الحمدلله - المشكلة انكشفت قبل لا توصل للعملاء!

مثال: نفس نظام القبول الجامعي

لو المختبر عمل test case:

• الطالب معدله 94% بالضبط
• عمره 25 سنة

النتيجة المتوقعة: ✅ مقبول النتيجة الفعلية: ❌ مرفوض

المختبر لقى المشكلة قبل أن النظام ينزل للـ Production ← هذه Defect.

المختبر يفعل ticket في Jira:

Title: Defect - Student with average 94% is incorrectly rejected
Priority: High
Environment: Testing

Bug (الخلل) - المشكلة في Production (اكتشفها Tester)

Bug هو نفس المشكلة (Defect) لكن عندما يكتشفها المختبر أو أي أحد يختبر في بيئة الإنتاج (Production).

متى نسمي المشكلة Bug؟

عندما:

• المشكلة موجودة في Production
• المختبر أو أحد من الفريق اكتشفها أثناء اختبار Production
• المشكلة انكشفت قبل أن المستخدم النهائي يتأثر فيها

مثال: نفس نظام القبول الجامعي

تخيل إنه:

• المختبر ما لقى هذه المشكلة في بيئة Testing
• النظام نزل Production
• المختبر أو أحد من الفريق عمل Sanity Testing في Production
• اكتشفوا إنه طالب معدله 94% النظام بيرفضه!

هون المشكلة صارت Bug لأنها انكشفت في Production من قِبل المختبر أو الفريق (مش من المستخدم النهائي).

Failure (الفشل) - المستخدم النهائي اكتشفها وتأثر

Failure هو عندما المستخدم النهائي (End User) يكتشف المشكلة ويتأثر فيها.

متى نقول صار Failure؟

عندما:

• المستخدم النهائي هو الذي اكتشف المشكلة (مش الـ Tester)
• المستخدم تضرر فعلياً من المشكلة
• المستخدم ما قدر يحقق هدفه بسبب المشكلة
• النظام فشل في تقديم القيمة للمستخدم الحقيقي

الـ Failure هو أسوأ سيناريو - المشكلة وصلت للمستخدم الحقيقي، هو الذي اكتشفها، وتأثر فيها سلباً!

مثال: نفس نظام القبول الجامعي

تخيل إنه:

• المختبر ما لقى المشكلة في Testing
• الفريق ما عمل Sanity Testing في Production
• طالب اسمه أحمد معدله 94% راح يسجل
• النظام رفضه!
• أحمد زعل، راح اشتكى لإدارة الجامعة

هون:

• Error: المبرمج كتب average > 94 بدل >= 94
• Failure: أحمد (المستخدم النهائي) هو الذي اكتشف المشكلة وتأثر فيها

الـ Failure هون خطير جداً لأنه:

• المستخدم النهائي هو الذي اكتشف المشكلة (مش الفريق)
• أثر على مستقبل شخص حقيقي
• سبب ضرر نفسي ومادي (أحمد راح يضيع سنة كاملة)
• أضر بسمعة الجامعة

الدورة الكاملة: من Error لـ Failure

خلينا نشوف كيف ينتقل الخطأ من المبرمج للمستخدم النهائي:

المبرمج كتب كود غلط
         ↓
 Error (خطأ بشري)
         ↓
    ┌──────────────────────────────────────────────┐
    │                                              │
    ↓                                              ↓
Defect                                           Bug
(المختبر لقاها في Testing) (المختبر لقاها في Production)
    │                                              │
    ↓                                              ↓
بنصلحه قبل Production بنصلحه بسرعة (Hotfix)
    │                                              │
    ↓                                              ↓
✅ ما صار Bug أو Failure ✅ ما صار Failure
                                                   │
 │ لو ما انتبهنا...
                                                   ↓
                                              Failure
 (المستخدم النهائي لقاها وتأثر)

أفضل سيناريو: ننكشف الـ Error ونصلحه قبل أن يصير Defect أصلاً!

سيناريو كويس: المختبر يلاقي Defect في Testing ونصلحه

سيناريو مقبول: المختبر يلاقي Bug في Production ونصلحه بسرعة قبل أن المستخدم يتأثر

أسوأ سيناريو: Failure - المستخدم النهائي يلاقي المشكلة ويتأثر فيها

مثال واقعي ثاني: Instagram Stories

خلينا ناخذ مثال من تطبيق الكل يستخدمه - Instagram.

السيناريو

تخيل إنه في feature جديدة: "نشر story بصورة متعددة (carousel)".

المتطلبات:

• المستخدم يقدر ينشر من 1 لـ 10 صور في story واحدة
• إذا حاول ينشر أكثر من 10 صور، النظام يعطيه رسالة خطأ واضحة

المبرمج كتب:

public boolean canPostStory(int numberOfPhotos) {
  if (numberOfPhotos > 0 && numberOfPhotos < 10) {// خطأ هنا!
    return true;
  } else {
    return false;
  }
}

Error: المبرمج كتب numberOfPhotos < 10 بدل <= 10

السيناريو الأول: انكشف Defect

المختبر جرّب:

• 1 صورة ← ✅ اشتغل
• 5 صور ← ✅ اشتغل
• 10 صور ← ❌ ما اشتغل! النظام رفض ينشر

المختبر لقى المشكلة في Testing ← هذه Defect.

الفريق صلّح الكود قبل أن ينزل Production ← ما صار Bug أو Failure.

السيناريو الثاني: المختبر لقى Bug في Production

تخيل إنه المختبر ما جرّب حالة الـ 10 صور في Testing.

النظام نزل Production، والمختبر عمل Sanity Testing في Production وجرّب ينشر 10 صور.

النظام رفض! المختبر اكتشف المشكلة.

هون: Bug - المختبر لقى المشكلة في Production قبل أن المستخدمين يتأثروا.

الفريق يقدر يعمل Hotfix بسرعة ويصلح المشكلة.

السيناريو الثالث: Failure - المستخدم اكتشفها

تخيل إنه:

• المختبر ما جرّب حالة الـ 10 صور في Testing
• الفريق ما عمل Sanity Testing في Production
• مستخدمة اسمها سارة حاولت تنشر story فيها 10 صور

النظام رفض! لا يوجد رسالة واضحة، لكن ما اشتغل.

سارة:

• حاولت 3 مرات
• زعلت
• اشتكت على Twitter: "Instagram app is broken! Can't post my vacation photos!"
• راحت استخدمت Snapchat بدل Instagram

هون: Failure - سارة (المستخدم النهائي) هي التي اكتشفت المشكلة وتأثرت فيها

ليش تعريفاتنا أفضل من ISTQB؟

ISTQB (المنظمة الدولية لاختبار البرمجيات) بتعرّف:

Bug = Defect (نفس الشي تماماً)

لكن إحنا منفرّق بينهم بناءً على وين انكشفت المشكلة.

ليش التفريق مهم عملياً؟

1. الـ Metrics والتقارير

عندما تقول لمديرك:

• "لقينا 50 Defect الأسبوع الماضي" ← عادي، هذا شغل المختبرين الطبيعي
• "طلع عنا 50 Bug في Production الأسبوع الماضي" ← مشكلة كبيرة! معناها الـ QA process فاشل

2. الـ Cost (التكلفة)

• إصلاح Defect في Testing ← رخيص (ساعة أو ساعتين شغل)
• إصلاح Bug في Production ← غالي جداً (Hotfix، deployment، خوف من مشاكل ثانية، تأثير على العملاء)

3. الـ Accountability (المسؤولية)

• Defect: المختبر عمل شغله صح ولقى المشكلة ← ✅ جيد
• Bug: المشكلة عدّت من Testing ووصلت Production ← ❌ في مشكلة بالـ process

4. الـ Urgency (الاستعجال)

• Defect: ممكن ننتظر للـ sprint الجاي أو نصلحه بهدوء
• Bug: لازم hotfix فوري خاصة إذا صار Failure

خلاصة الدرس

دعونا نلخص المصطلحات الأربعة:

✅ Error (الخطأ): خطأ بشري من المبرمج أثناء كتابة الكود

✅ Defect (العيب): المشكلة عندما المختبر يلاقيها في بيئة Testing (قبل Production)

✅ Bug (الخلل): المشكلة عندما المختبر أو الفريق يلاقيها في Production (قبل أن المستخدم يتأثر)

✅ Failure (الفشل): عندما المستخدم النهائي يلاقي المشكلة ويتأثر فيها

✅ الفرق بين Defect و Bug و Failure - الفرق بالـ من اكتشفها ووين

✅ ISTQB بيعتبر Bug = Defect، لكن تعريفنا العملي أوضح وأفضل للتقارير والـ metrics

✅ الهدف: ننكشف كل الـ Errors كـ Defects في Testing، ونمنعهم يوصلوا Production كـ Bugs

اختبر فهمك - Quiz

السؤال الأول

مبرمج كتب في نظام حجز طيران:

if (passengerAge > 2) {
  ticketPrice = 100;
} else {
  ticketPrice = 0;// مجاني للأطفال
}

المتطلبات كانت: الأطفال سنتين أو أقل مجاني، الباقي بـ 100 دولار.

ما اسم المشكلة هون؟

السؤال الثاني

نفس المشكلة من السؤال الأول - المختبر عمل test case لطفل عمره سنتين ولقى إنه النظام يطلب منه يدفع 100 دولار.

هذا أصبح هناك بيئة الـ Testing.

ما اسم المشكلة هون؟

السؤال الثالث

نفس المشكلة - لكن هالمرة المختبر ما لقاها في Testing.

النظام نزل Production، والمختبر عمل Sanity Testing ولقى إنه طفل عمره سنتين النظام يطلب منه 100 دولار.

ما اسم المشكلة هون؟

السؤال الرابع

نفس المشكلة - لكن المختبر ما عمل Sanity Testing في Production.

عائلة رحلت على دبي، وطفلهم عمره سنتين. عندما حاولوا يحجزوا تذاكر، النظام طلب منهم يدفعوا 100 دولار للطفل.

العائلة دفعت الـ 100 دولار الزيادة (مع إنه المفروض مجاني). بعد ذلك اكتشفوا الخطأ، زعلوا، وكتبوا review سيء للشركة على Google.

ما اسم المشكلة هون؟

السؤال الخامس

حسب تعريفات ISTQB، الـ Bug والـ Defect:

أ) مختلفين تماماً ب) نفس الشي ج) Bug أخطر من Defect د) Defect يحصل قبل Bug

الخطوة القادمة

في الدرس الجاي، رح نحكي عن Severity vs Priority - شو الفرق بينهم؟ ومتى نعطي مشكلة High Severity بس Low Priority؟

استعد لأمثلة واقعية من Facebook و WhatsApp و Uber!

ملاحظة أخيرة:

لا تحفظ التعريفات - افهمها وطبقها! الهدف مش إنك تحفظ "Defect هو كذا" - الهدف إنك عندما تلاقي مشكلة، تعرف كيف توصفها بدقة وتعرف ما الـ action المناسب.

شكراً ويعطيكم العافية! 🚀