دورة حياة الـ Bug — Defect Life Cycle خطوة بخطوة

المختبر المبتدئ بيعتقد إنّ شغله يخلص لمّا يضغط «Create» على الـ Bug. الحقيقة إنّ هون بيبدأ: الـ Bug من لحظة فتحه لحد إغلاقه بيمرّ بسلسلة حالات، وكل حالة إلها مالك وشرط انتقال وسبب فشل ممكن يوقف الـ Bug فيها لأسابيع.

الفرق بين مختبر بيفتح Bugs ومختبر بيوصّل Bugs لحد الإصلاح هو فهم هذي الدورة. هذا المقال بيمشي عليها حالة حالة.

المسار الأساسي بسطر

New → Assigned → In Progress → Fixed → Retest → Closed

وأي انحراف عن هذا المسار بيروح لواحدة من: Rejected أو Duplicate أو Deferred أو Reopened.

الحالات وحدة وحدة

1) New — الـ Bug انفتح

المختبر لاقى سلوك مخالف للمتوقّع، أعاد إنتاجه، وكتب تقرير Bug واضح: بيئة، خطوات، نتيجة فعلية، نتيجة متوقّعة، Severity، ومرفقات (صورة أو تسجيل).

المالك: المختبر.
شرط الخروج: التقرير مفهوم وقابل لإعادة الإنتاج من غيرك.
أشهر سبب تعطّل هون: Bug مكتوب بجملة واحدة («البحث ما بيشتغل») بلا خطوات ولا بيئة — بيرجع للمختبر بعد يومين ضايعين.

2) Assigned — انتسب لحدا

قائد الفريق أو مدير المشروع بيحدّد مين رح يشتغل عليه. بفرق صغيرة، المختبر بينسبه مباشرة للمطوّر المسؤول عن الوحدة.

المالك: قائد الفريق / مدير المشروع.
شرط الخروج: اسم شخص محدّد، مش «الفريق».

3) In Progress — الإصلاح جاري

المطوّر بيحلّل ويصلّح. هون شغل المختبر إنّه يكون متاح للأسئلة: أي جهاز، أي حساب، أي بيانات.

المالك: المطوّر.

4) Fixed — الإصلاح خلص (وما بعد اختباره!)

هذي أخطر حالة بالدورة، لأنّ كثير ناس بتفهمها إنّها «خلصت». Fixed معناها المطوّر خلّص شغله، وبتنطر إعادة اختبار. الـ Bug لسا مفتوح من ناحية الجودة.

المالك: المختبر (بانتظار نسخة فيها الإصلاح).
شرط الخروج: الإصلاح منشور على بيئة الاختبار — مش على جهاز المطوّر.

5) Retest — إعادة الاختبار

المختبر بينفّذ نفس خطوات التقرير على النسخة الجديدة (هذا اللي بيتسمّى Retesting أو Confirmation Testing)، وبعدها بيعمل فحص انحدار للمسارات المرتبطة.

النتيجة إمّا:

انصلح → Closed
لسا موجود أو انصلح جزئياً → Reopened

راجع الفرق بين Smoke و Sanity و Regression لتعرف قد إيش توسّع الفحص هون.

6) Closed — إغلاق موثّق

المختبر بيغلق الـ Bug مع تعليق واضح: على أي نسخة/build تأكّد الإصلاح، وشو المسارات اللي فُحصت.

المالك: المختبر — الإغلاق مسؤوليّة المختبر، مش المطوّر. هذي قاعدة ذهبية: اللي فتح الـ Bug هو اللي يغلقه.

الحالات الفرعية اللي بتصير كثير

Rejected — مرفوض

المطوّر أو المحلّل شاف إنّه مش Bug. الأسباب المشروعة: السلوك مطابق للمتطلب، أو المختبر استخدم بيانات/بيئة غلط، أو المتطلب نفسه بيقول هيك.

شو تعمل: ما تجادل بالمشاعر — جادل بالمرجع. ارجع للمتطلب أو الـ Acceptance Criteria وأرفق السطر. إذا المتطلب نفسه غامض، هذا مكسب أكبر: الـ Bug صار Bug متطلبات، وبينحلّ من الجذر.

Duplicate — مكرّر

نفس الـ Bug مفتوح قبل. المسؤولية هون على المختبر: دوّر قبل ما تفتح. بحث سريع بالكلمة المفتاحية بالـ Backlog بيوفّر تكرار.

Not Reproducible / Cannot Reproduce — ما قدروا يعيدوا إنتاجه

أشهر سبب: بيئة أو بيانات أو جهاز مختلف، أو خطوة ناقصة من التقرير.

شو تعمل: أضف تسجيل شاشة، اسم الحساب المستخدم، إصدار نظام التشغيل والجهاز، وقت الحدوث، والـ build. وإذا الـ Bug متقطّع (intermittent)، اكتب صريح: «ظهر 3 مرّات من 10 محاولات» — هذي معلومة تشخيصية، مش ضعف بالتقرير.

Deferred / Postponed — مؤجّل

الـ Bug حقيقي، بس القرار إنّه ما ينصلح هلأ. غالباً Severity عالية مع Priority منخفضة — راجع الفرق بين Severity و Priority.

المهم هون: يُسجّل بالـ Backlog مع سبب التأجيل وتاريخ مراجعة، مش يُنسى.

Reopened — انفتح من جديد

الإصلاح فشل، أو صلّح الظاهر وما صلّح السبب.

نصيحة: بتعليق واحد وضّح شو اللي فشل بالضبط، وعلى أي build، وشو الجديد اللي لاحظته — لتوفّر دورة أسئلة.

Won’t Fix — لن يُصلَح

قرار نهائي إنّ الـ Bug رح يفضل. بيصير لأسباب تكلفة أو لأنّ الميزة رح تُشال. المهم إنّه يوصل لفريق الدعم لتكون الإجابة موحّدة للمستخدمين.

جدول: مين مالك كل حالة

الحالة	المالك	الخطوة الجاية
New	المختبر	ينتسب لشخص
Assigned	قائد الفريق	يبدأ الإصلاح
In Progress	المطوّر	ينشر الإصلاح على بيئة الاختبار
Fixed	المختبر	إعادة اختبار
Retest	المختبر	إغلاق أو إعادة فتح
Rejected	المختبر	يرفق المرجع أو يتقبّل الرفض
Deferred	Product Owner	مراجعة بموعد محدّد
Reopened	المطوّر	إصلاح جديد
Closed	—	الأرشيف والتقارير

المسار على Jira

على Jira، هذي الحالات بتظهر كـ Workflow لنوع الـ Bug، والانتقال بينها بيصير بزرّ Transition. نصايح عملية:

خلّي الـ Workflow قصير: خمس أو ست حالات بتكفي. Workflow فيه 12 حالة محدا رح يمشي عليه صح.
اشترط تعليق عند Rejected و Reopened — هيك ما بتضيع الأسباب.
استخدم Resolution (Fixed / Duplicate / Won’t Fix / Cannot Reproduce) بدل ما تعمل حالة لكل واحد.
بتقاريرك، عدّ الـ Bugs المفتوحة حسب Severity، مش العدد الكلي — العدد الكلي ما بيقول شي عن جاهزية الإصدار.

كل هذا موجود عملياً بـ دورة Jira من الصفر للاحتراف.

ثلاثة مؤشّرات بتقول إنّ دورتك صحّية

نسبة Rejected: لو أعلى من 10–15%، غالباً المشكلة بجودة التقارير أو بغموض المتطلبات.
نسبة Reopened: لو عالية، الإصلاحات سطحية أو إعادة الاختبار ناقصة.
عمر الـ Bug (Age): Bugs Critical عمرها أسابيع = مشكلة أولويات، مش مشكلة اختبار.

أسئلة شائعة

مين يغلق الـ Bug: المطوّر ولا المختبر؟ المختبر. المطوّر بينقله لـ Fixed، والمختبر بيتحقّق وبيغلق.

شو الفرق بين Fixed و Closed؟ Fixed = المطوّر خلّص. Closed = المختبر تأكّد. الاثنين مش نفس شي، والخلط بينهم بيخلّي Bugs غير مُتحقَّق منها تُحسب مُنجَزة.

الـ Bug اترفض وأنا متأكّد إنّه Bug — شو أعمل؟ ارجع للمتطلب أو الـ Acceptance Criteria وأرفق السطر بالتعليق. إذا ما فيه مرجع واضح، حوّل النقاش لسؤال متطلبات مع Product Owner.

شو الفرق بين Error و Defect و Failure؟ Error خطأ بشري، بينتج عنه Defect بالكود أو بالوثيقة، واللي لمّا ينفّذ بيسبّب Failure بالسلوك. الترتيب هذا بيتسأل بامتحان ISTQB CTFL.

هل لازم كل Bug يمرّ بكل الحالات؟ لأ. المسار الأساسي هو المتوقّع، والحالات الفرعية بتظهر حسب الحاجة.

خطوتك الجاية

اكتب الـ Bug بشكل ما يترجّع: كيف تكتب Bug Report ما يرجعلك.
رتّب الـ Bugs صح: Severity و Priority.
شوف الصورة الكبيرة: STLC — دورة حياة الاختبار.