إدارة العيوب

إدارة العيوب

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

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

ما هو العيب؟

العيب (ويُسمى أيضاً الخطأ البرمجي أو الخلل أو المشكلة) هو أي انحراف بين السلوك الفعلي للنظام والسلوك المتوقع كما هو محدد في متطلب معتمد أو معيار قبول أو معيار متفق عليه. التعريف مهم: العيب ليس مجرد شيء لا يُعجب المختبِر — يجب أن يكون قابلاً للتتبع إلى توقع موثق. لهذا السبب تترابط إمكانية تتبع المتطلبات (التي تناولناها في الدرس السادس) ارتباطاً وثيقاً بإدارة العيوب.

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

دورة حياة العيب

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

استعراض الحالات الرئيسية:

• New (جديد) — يسجّل مختبِر أو محلل أو مستخدم العيب. لا حكم بعد على صحته أو أولويته.
• Open (مفتوح) — تؤكد جلسة الفرز (أو مسؤول الفرز المُعيَّن) أن العيب حقيقي، وتحدد خطورته وأولويته وتسنده إلى مطور. العيوب المكررة أو غير القابلة للإعادة أو تلك التي تعمل كما هو مصمّم تنتقل إلى Rejected (مرفوض). العيوب الصحيحة التي لا يُخطط لمعالجتها في هذا الإصدار تنتقل إلى Deferred (مؤجَّل).
• In Progress (قيد التنفيذ) — المطور يحقق بنشاط ويكتب الإصلاح.
• Fixed (مُصلَح) — ينشر المطور الإصلاح في بيئة الاختبار ويُعلّم العيب مُصلَحاً. على المُبلِّغ الأصلي (أو مُحقِّق مُعيَّن) إعادة الاختبار الآن.
• Closed (مُغلَق) — تؤكد إعادة الاختبار أن الإصلاح يعمل ولم يُدخَل أي انحدار. يُغلَق العيب.
• Reopened (مُعاد فتحه) — تكشف إعادة الاختبار أن الإصلاح ناقص أو أدخل مشكلة جديدة. يعود العيب إلى المطور.

تسجيل العيب بشكل جيد

تقرير عيب لا يمكن إعادة إنتاجه يُهدر وقت الجميع. مسؤولية المحلل — سواء سجّل العيوب بنفسه أو درّب المختبِرين — هي ضمان أن كل تقرير يحتوي على ما يكفي من المعلومات لكي يتمكن مطور لم يكن في الغرفة من إعادة إنتاج المشكلة بالضبط. الحقول المعيارية هي:

• العنوان — وصف دقيق في سطر واحد: "المتجر الإلكتروني: يعرض إجمالي السلة $0 عند تطبيق كود خصم بنسبة 100%" — وليس "الإجمالي خاطئ".
• البيئة — المتصفح/نظام التشغيل/الجهاز، رقم الإصدار والبيلد، اسم بيئة الاختبار.
• الشروط المسبقة — ما يجب أن يكون صحيحاً قبل البدء: "المستخدم مسجّل دخوله، السلة تحتوي على عنصرين، كود SUMMER100 نشط."
• خطوات الإعادة — تسلسل مرقّم يُحفّز العيب بشكل موثوق. إذا كان العيب متقطعاً، وثّق التكرار.
• النتيجة الفعلية — بالضبط ما فعله النظام.
• النتيجة المتوقعة — ما تنص عليه المتطلبات أو معيار القبول المعتمد، مع المرجع (مثلاً: REQ-142).
• الخطورة (Severity) — الأثر التقني: حرجة / عالية / متوسطة / منخفضة.
• الأولوية (Priority) — الإلحاح التجاري: ما مدى استعجال الإصلاح؟
• المرفقات — لقطات الشاشة وتسجيلات الشاشة ومقتطفات السجلات.

تصنيفات الخطورة

تعتمد معظم المنظمات مقياساً رباعياً للخطورة:

• حرجة (S1) — تعطّل النظام، فقدان البيانات، اختراق أمني، أو انسداد مسار عمل أساسي بلا حل بديل. مثال: يتعطل نظام حجز العيادة عند محاولة الموظف إلغاء موعد.
• عالية (S2) — وظيفة رئيسية معطوبة لكن النظام يعمل. قد يتوفر حل بديل لكنه غير عملي للاستخدام اليومي. مثال: لا تستطيع بوابة اللوجستيات توليد بيانات الشحن — الموظفون يُنشئونها يدوياً.
• متوسطة (S3) — الميزة تعمل لكن ليس بشكل صحيح في ظروف معينة. حل بديل متاح. مثال: يعرض المتجر الإلكتروني رمز عملة خاطئاً للمستخدمين في أوروبا.
• منخفضة (S4) — مشكلات تجميلية أو ثانوية: تسمية خاطئة، اختلال طفيف في المحاذاة، خطأ إملائي في تلميح. وظيفة النظام غير متأثرة.

الفرز: اجتماع القرار

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

خلال الفرز، يجب أن يخرج كل عيب في حالة New بإحدى أربع حالات: Open (صالح، مجدوَل لهذا الإصدار)، أو Rejected (ليس عيباً)، أو Deferred (صالح لكن ليس لهذا الإصدار)، أو يعود إلى New إذا احتاج مزيداً من المعلومات من المُبلِّغ.

تقرير العيب — مثال تطبيقي

فيما يلي سجل عيب مكتمل لنظام حجز مواعيد العيادة:

مقاييس العيوب وتقارير الجودة

بيانات العيوب معلومات استخباراتية للمشروع. ينبغي للمحلل وقائد ضمان الجودة تتبع هذه المقاييس الرئيسية وإعداد تقارير عنها بانتظام:

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

أنماط مضادة شائعة في إدارة العيوب

انتبه لهذه الأعطال على المشاريع الحقيقية:

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

دور المحلل في إدارة العيوب

محلل الأنظمة ليس مراقباً سلبياً في عملية العيوب. إسهاماتك الملموسة هي:

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

خلاصة

• العيب هو انحراف عن متطلب موثق أو معيار قبول — لا مجرد شيء لا يُعجب المختبِر.
• تسير دورة حياة العيب من New ← Open ← In Progress ← Fixed ← Closed، مع مسارات فرعية للحالات Rejected وDeferred وReopened.
• يتضمن تقرير العيب المكتمل العنوان والبيئة والشروط المسبقة وخطوات الإعادة المرقّمة والنتيجة الفعلية والمتوقعة (مع مرجع المتطلب) والخطورة والأولوية والمرفقات.
• الخطورة تقيس الأثر التقني؛ الأولوية تقيس الإلحاح التجاري — وهما مستقلان ويجب تحديدهما منفصلَين.
• الفرز اجتماع قرار منظّم يؤكد الصلاحية ويحدد الخطورة والأولوية ويُسنِد الملكية.
• مقاييس العيوب — معدل الاكتشاف والإغلاق والعدد المفتوح حسب الخطورة ومعدل إعادة الفتح — توفر دليلاً موضوعياً على جاهزية الإصدار.
• يمتد دور المحلل ليشمل تأليف المتطلبات والمشاركة في الفرز وتحليل الأنماط وإعادة الاختبار على مستوى القبول.