دورة حياة العيب (Defect Lifecycle)

الخطأ والعيب والإخفاق: ضبط المصطلحات

يصف مسرد ISTQB ومنهج المستوى التأسيسي سلسلة سببية. يرتكب شخص خطأً (Error) ويسمى أيضاً (Mistake): يسيء فهم متطلب، أو ينسى حداً، أو يكتب عاملاً خاطئاً. وينتج عن الخطأ عيب (Defect) ويسمى أيضاً (Fault) أو (Bug) في أحد منتجات العمل — متطلب، أو تصميم، أو الشيفرة، أو سكربت اختبار، أو إعداد. وعندما يُنفَّذ الجزء المعيب في الظروف المناسبة قد يسبب إخفاقاً (Failure): لا يفعل النظام ما يجب عليه، ويلاحظ ذلك شخص أو نظام ما. وليس كل عيب يسبب إخفاقاً — فالعيب في شيفرة لا تُنفَّذ أبداً، أو لا تُنفَّذ إلا ببيانات لا يدخلها أحد، يبقى كامناً — ويشير المنهج أيضاً إلى أن الإخفاقات قد تنشأ كذلك عن ظروف بيئية.

وهناك كلمتان أخريان تسببان الالتباس. الشذوذ (Anomaly) هو المصطلح المحايد: انحراف ملاحَظ عن المتوقع قبل أن يقرر أحد هل هو عيب أم سوء فهم أم خطأ في الاختبار أم طلب تغيير. ويستخدم معيار IEEE 1044 لتصنيف شذوذات البرمجيات (المدرج لدى IEEE كمعيار غير نشط محفوظ) هذه الكلمة مصطلحاً جامعاً ويعرّف سمات لتصنيف الشذوذات. أما الحادثة (Incident) فكلمة محمّلة بأكثر من معنى: يسمّي المعيار ISO/IEC/IEEE 29119-3 تقرير العيب «تقرير حادثة» (Incident report)، كما ينبّه منهج ISTQB التأسيسي، بينما الحادثة في العمليات هي انقطاع أو تدهور غير مخطط في خدمة حية، قد يسببه عيب أو السعة أو الإعدادات أو طرف ثالث.

• الخطأ (Error / Mistake) — فعل بشري ينتج عنه نتيجة غير صحيحة.
• العيب (Defect / Fault / Bug) — خلل في منتج عمل؛ ويمكن اكتشافه بالمراجعة دون تشغيل أي شيء.
• الإخفاق (Failure) — انحراف ملاحَظ في سلوك النظام أثناء التشغيل عن السلوك المتوقع.
• السبب الجذري (Root cause) — السبب الأعمق لارتكاب الخطأ أو لعدم منع العيب؛ وهو هدف تحليل السبب الجذري.
• الشذوذ (Anomaly) — أي انحراف ملاحَظ عن المتوقع لم يُصنَّف بعد.

أين تُكتشف العيوب: المراجعات والاختبار والإنتاج

تدخل العيوب في كل مرحلة من دورة حياة تطوير البرمجيات (SDLC) وتُكتشف في نقاط مختلفة منها. المتطلب الذي يناقض متطلباً آخر عيب تكشفه المراجعة قبل وجود أي شيفرة. والحساب الخاطئ يكشفه اختبار وحدة أو اختبار API أو اختبار نظام خلال دورة حياة اختبار البرمجيات (STLC). والعيب الذي يفلت من كل فحص يُكتشف في الإنتاج، عادةً كإخفاق يبلّغ عنه مستخدم أو تنبّه إليه المراقبة. يصف دليل SDLC وSTLC ودليل دورة حياة اختبار البرمجيات هذه المراحل؛ أما هذه الصفحة فتصف ما يحدث للعيب بعد اكتشافه.

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

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

حالات دورة الحياة في مخطط

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

• جديد (New) — مسجَّل ولم يُراجَع بعد. تسميه بعض المتتبّعات Unconfirmed أو Submitted أو Untriaged.
• بحاجة إلى معلومات (Needs info) — ينتظر معلومة محددة من المبلِّغ؛ وعدّاد العمر يستمر.
• مفتوح / مُسنَد (Open / Assigned) — مقبول كعيب صالح، وله خطورة وأولوية ومالك وإصدار مستهدف.
• قيد العمل (In Progress) — المالك يحقق فيه أو يصلحه فعلياً.
• محلول (Resolved) — يرى المالك أن العمل انتهى، إما بالإصلاح أو بقرار آخر.
• مُعاد فتحه (Reopened) — لم يصمد القرار؛ يعود العيب إلى مالكه.
• متحقَّق منه (Verified) — أكّد مختبِر الإصلاح في البناء المذكور.
• مغلق (Closed) — لا عمل إضافياً؛ ويبقى السجل للتاريخ والمقاييس.
• مؤجل (Deferred) — صالح لكنه مؤجل عن وعي إلى إصدار لاحق؛ ويظل محسوباً عيباً مفتوحاً معروفاً.

  failure observed, or defect found in a review
                 |
                 v
             [ New ] ----- facts missing -----> [ Needs info ]
                 |  <------ facts supplied ------------+
                 |
                 +------- triage: no fix needed ------> [ Resolved ]  duplicate | rejected (not a bug)
                 |                                           |         cannot reproduce | won't fix | by design
                 | triage: accepted                          |
                 v                                           | reporter / QA agrees (if not: back to triage)
        [ Open / Assigned ] <----- re-planned -----+         |
             |        |                            |         |
             |        +------ postpone ----> [ Deferred ]    |
             | developer starts                              |
             v                                               |
        [ In Progress ]                                      |
             +-- cannot reproduce --> back to [ Needs info ] |
             | fix merged, build number stated               |
             v                                               |
     [ Resolved: fixed ] -- retest fails --> [ Reopened ] --> back to [ Open / Assigned ]
             |                                               |
             | confirmation test passes, regression green    |
             v                                               v
        [ Verified ] ------- fix shipped ------------> [ Closed ]
                                                             |
                                same failure seen again -----+--> [ Reopened ]

الانتقالات: من يحرّك العيب وما الذي يجب أن يتحقق

لا تفيد الحالة إلا إذا عرف الجميع من يحق له نقل العيب منها وما الذي يجب أن يتحقق أولاً. ضع هذه القواعد في مسار العمل في المتتبّع حيث يدعم الشروط والحقول الإلزامية، وفي اتفاق عمل الفريق حيث لا يدعمها.

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

نهايات غير «مُصلَح»

كثير من سجلات العيوب ينتهي دون أي تغيير في الشيفرة. ويشير منهج ISTQB التأسيسي إلى أن الشذوذ المبلَّغ عنه قد لا يكون عيباً أصلاً — بل إيجابية كاذبة (False positive) أو طلب تغيير مثلاً. وكل نهاية دون إصلاح تحتاج إلى سبب يستطيع القارئ التحقق منه بعد أشهر.

• مكرر (Duplicate) — العيب نفسه مسجَّل مسبقاً. اربطه بالأصل، وانقل أي دليل أفضل، واحسم السجل الأحدث. العَرَض نفسه لا يعني دائماً السبب نفسه؛ وإن كنت غير متأكد فأبقِ الاثنين مرتبطين حتى يثبت الإصلاح ذلك.
• مرفوض / غير صالح / ليس خطأ (Rejected / Invalid / Not a bug) — السلوك مطابق للمتطلب، أو نشأ البلاغ عن خطأ في الاختبار كبيانات خاطئة أو بيئة خاطئة. اقتبس المتطلب. وإن كان المتطلب نفسه خاطئاً فذلك عيب في المتطلبات أو طلب تغيير، لا رفض.
• تعذّر إعادة الإنتاج / يعمل لديّ (Cannot reproduce / Works for me) — لا أحد يستطيع إحداث الإخفاق مجدداً بالمعلومات المتاحة. سجّل ما جُرّب (الإصدارات والأجهزة والبيانات) واحتفظ بالسجلات ومعرّفات الطلبات: العيوب المتقطعة كثيراً ما تعود، والبلاغ الأول هو الدليل.
• لن يُصلَح (Won't fix) — عيب حقيقي قرر الفريق عدم إصلاحه، عادةً لأن التكلفة تفوق الأثر أو لأن الميزة في طريقها إلى الإلغاء. وهو قرار عمل يملكه مالك المنتج ويُسجَّل مع سببه.
• مؤجل (Deferred) — عيب حقيقي مؤجل إلى إصدار لاحق. وخلافاً لـ «لن يُصلَح» يبقى مفتوحاً ومكانه قائمة المشكلات المعروفة التي تُرفق بملاحظات الإصدار.
• حسب التصميم (By design / As designed) — السلوك مقصود. وعندما يفاجئ التصميم المستخدمين، فكّر هل هذه المفاجأة بحد ذاتها عيب في قابلية الاستخدام يستحق سجلاً مستقلاً.

كيف تسمّيها المتتبّعات: Bugzilla وJira وغيرهما

تصف وثائق Bugzilla مسار عمل الأخطاء بأنه قابل للتخصيص وتعرض مساراً افتراضياً. في المسار الافتراضي تكون الحالات UNCONFIRMED وCONFIRMED وIN_PROGRESS وRESOLVED وVERIFIED، ويحمل الخطأ المحلول أحد القرارات (Resolutions) التالية: FIXED أو INVALID أو WONTFIX أو DUPLICATE أو WORKSFORME. ويصف شرح الحقول في Bugzilla حالة VERIFIED بأنها النقطة التي راجع فيها فريق الجودة الخطأ وقراره ووافق عليه، وبأنها الحالة النهائية. وهناك خياران تصميميان يستحقان النسخ: القرار حقل منفصل عن الحالة، و«تعذّر إعادة الإنتاج» نهاية رسمية لا مجرد تعليق.

أما Jira فيسلك طريق التهيئة: كل مسار عمل يحدد حالاته وانتقالاته، ويختار المسؤولون القرارات (Resolutions) المتاحة، فقد يستخدم مشروعان في الشركة نفسها أسماء ومسارات مختلفة لدورة الحياة نفسها. وتكتفي متتبّعات المشكلات الخفيفة تقريباً بحالتي مفتوح ومغلق، ويعبّر الفريق عن الباقي بالتسميات (needs-info وduplicate وwontfix) وبطلبات السحب أو الدمج المرتبطة. وأياً كانت الأداة، احتفظ بجدول من صفحة واحدة يربط أسماء متتبّعك بدورة الحياة العامة حتى تعني المقاييس الشيء نفسه عبر المشاريع.

ويقرأ الجدول أدناه هكذا: «جديد» يقابل UNCONFIRMED في Bugzilla، ويقابل في مشروع Jira المُتَّخذ مثالاً حالةَ Open مع التسمية untriaged؛ و«مفتوح / مُسنَد» يقابل CONFIRMED مع مُسنَد إليه، وTo Do مع مُسنَد إليه؛ و«قيد العمل» يقابل IN_PROGRESS وIn Progress؛ و«محلول: مُصلَح» يقابل RESOLVED بقرار FIXED، وReady for QA بقرار Fixed؛ و«محلول: غير ذلك» يقابل RESOLVED بقرار INVALID أو WONTFIX أو DUPLICATE أو WORKSFORME، وDone بقرار Duplicate أو Won't Do أو Cannot Reproduce؛ و«متحقَّق منه» يقابل VERIFIED، وهي الحالة النهائية في Bugzilla، وVerified في Jira؛ أما «مغلق» فلا حالة منفصلة له في مسار Bugzilla الافتراضي، ويقابله Closed في Jira.

Generic state      Bugzilla default               Example Jira project (configured)
-----------------  -----------------------------  ---------------------------------
New                UNCONFIRMED                    Open + label "untriaged"
Open / Assigned    CONFIRMED + assignee           To Do + assignee
In Progress        IN_PROGRESS                    In Progress
Resolved: fixed    RESOLVED / FIXED               Ready for QA, resolution Fixed
Resolved: other    RESOLVED / INVALID, WONTFIX,   Done, resolution Duplicate,
                   DUPLICATE, WORKSFORME          Won't Do, Cannot Reproduce
Verified           VERIFIED (final status)        Verified
Closed             (no separate state)            Closed

اختبار التأكيد واختبار الانحدار وإعادة الفتح

يتبع الإصلاح اختباران مختلفان، ويسميهما منهج ISTQB كلاً على حدة. اختبار التأكيد (Confirmation testing)، ويسمى كثيراً إعادة الاختبار (Retesting)، يعيد تنفيذ الخطوات التي فشلت، في البناء الذي يحتوي الإصلاح، للتأكد من زوال العيب. واختبار الانحدار (Regression testing) يتحقق من أن التغيير لم يكسر شيئاً آخر: الميزات المجاورة، والمستدعين الآخرين للشيفرة المعدّلة، والمنصات واللغات الأخرى. يُعدّ العيب متحقَّقاً منه عندما ينجح الأول؛ ولا يكون الإصدار آمناً إلا عندما ينجح الثاني أيضاً.

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

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

جرّبها: مولّد سيناريوهات الانحدار

مثال تطبيقي: عيب واحد من الاكتشاف حتى الإغلاق

ما يلي عيب افتراضي في تطبيق بيع بالتجزئة افتراضي، ببيانات واقعية. الأسعار بالريال السعودي مع ضريبة القيمة المضافة 15%، وقاعدة المنتج في هذا المثال أن الضريبة تُحتسب على السعر بعد الخصم.

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

DEF-2417  Android checkout charges 190.00 SAR instead of 184.00 with a fixed-amount coupon
Found in: system testing, release 5.3.0     Reporter: layla.h@example.com
Environment: Android app 5.3.0 (build 530-rc2), Android 14 emulator, staging, API v2

2026-09-14 09:40  NEW          Cart 200.00 SAR, coupon SAVE40 (-40.00). Expected (200 - 40) x 1.15 = 184.00.
                               Actual: charged 190.00 (VAT 30.00 computed on 200.00, then -40.00).
                               Web checkout, same account: correct. Request and response attached.
                               Reported severity: Major.
2026-09-14 14:00  OPEN         Triage: reproduced 3/3 by a second tester; no duplicate ("VAT", "coupon").
                               Severity raised to Critical (customer charged a wrong amount).
                               Priority Highest (release 5.3.0 due 2026-09-21).
                               Owner: omar.k (payments API). Target: 5.3.0.
2026-09-15 10:15  IN PROGRESS  API v2 POST /orders/price applies the coupon after VAT; v1 was changed
                               in 5.1 when the rule changed, v2 was not.
2026-09-15 17:30  RESOLVED     Fixed in build 530-rc3. API tests added for fixed and % coupons.
2026-09-16 11:05  REOPENED     Retest on rc3: amount charged is 184.00, but the order summary before
                               payment still shows 190.00 (GET /orders/summary, v2). Same defect.
2026-09-16 11:20  OPEN         Back to omar.k with the retest evidence. Target unchanged: 5.3.0.
2026-09-16 13:40  IN PROGRESS  GET /orders/summary (v2) still calls the old pricing function.
2026-09-16 18:20  RESOLVED     Fixed in build 530-rc4: summary uses the corrected pricing function.
2026-09-17 12:40  VERIFIED     Confirmation on rc4: 184.00 on both screens; also 20% coupon, web and
                               Android. Regression: checkout and pricing pack 38/38 passed.
2026-09-21 16:00  CLOSED       Shipped in 5.3.0.

Age at verification: 3 d 3 h   Reopen count: 1   Found in: system test
Root cause origin: requirements (rule change scoped to web only); contributing: code, test

جرّبها: فاحص طلبات HTTP جرّبها: محلّل استجابات API جرّبها: مولّد وصف الأخطاء بالذكاء الاصطناعي

تقادم العيوب ومقاييسها وتقارير الملخص

عمر العيب (Defect age) هو المدة التي ظل فيها مفتوحاً: من الإنشاء حتى الآن للعيوب المفتوحة، أو حتى الحل أو الإغلاق للعيوب المنتهية — اختر تعريفاً واحداً والتزم به. والزمن في كل حالة أنفع من العمر الكلي، لأنه يُظهر أين تنتظر العيوب: الأيام في «جديد» تعني أن الفرز لا يحدث؛ والأيام في «محلول» تعني أن طابور إعادة الاختبار هو عنق الزجاجة؛ والأيام في «بحاجة إلى معلومات» تعني أن التقارير تنقصها الحقائق.

عدد قليل من مقاييس العيوب يدعم قرارات حقيقية: العيوب المفتوحة حسب الخطورة والعمر (جاهزية الإصدار)، والوارد مقابل المغلق عبر الزمن (هل يتقارب المتراكم؟)، ومعدل إعادة الفتح (جودة الإصلاح)، ومعدل المرفوض والمكرر (جودة التقارير والبحث في المتتبّع)، ونسبة العيوب المكتشفة في كل مرحلة مقارنة بالإنتاج — وهي الفكرة وراء نسبة اكتشاف العيوب (Defect detection percentage) في مسرد ISTQB. ويغطي دليل مقاييس الاختبار التعريفات والصيغ وكيف يُتلاعب بالمقاييس.

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

• حدّد عتبات عمر لكل مستوى خطورة — مثلاً عيب Critical لم يُفرز بعد يوم عمل واحد، أو عيب Major في «محلول» لأكثر من ثلاثة أيام — وراجع التجاوزات كل أسبوع.
• أبلغ عن العيوب المؤجلة صراحة؛ فالعيب المؤجل مخاطرة معروفة في الإصدار، لا عيب مغلق.

Defect summary - release 5.3.0 - week ending 2026-09-18
Open by severity:     Blocker 0 | Critical 1 | Major 6 | Minor 14 | Trivial 9   (total 30)
Arrivals / closures:  23 / 31 this week (backlog down 8)
Age of open defects:  under 7 d: 18 | 7-30 d: 9 | over 30 d: 3 (all Minor, deferred to 5.4)
Reopen rate:          3 of 58 fixes in the last 4 weeks (5%)
Found in:             reviews 11 | system test 37 | UAT 6 | production 2
Release-relevant:     DEF-2451 Critical / Highest / omar.k - fix in rc5, retest 2026-09-19
Deferred, risk accepted by product owner on 2026-09-17: DEF-2290, DEF-2304

إدارة دورة الحياة جيداً: قائمة تحقق

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

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

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

الأسئلة الشائعة

المراجع

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• ISTQB GlossaryISTQBالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
• IEEE 1044-2009 — IEEE Standard Classification for Software AnomaliesIEEE Standards Association · 2009مفردات وسمات قياسية لتصنيف شذوذات البرمجيات — العيوب والإخفاقات وأثرها (مدرج لدى IEEE كمعيار غير نشط محفوظ).
• Editing a Bug (section "Life Cycle of a Bug") — Bugzilla DocumentationBugzilla Project (Mozilla)سير العمل الافتراضي للأخطاء في متتبّع واسع الاستخدام — الحالات والقرارات (مُصلَح، غير صالح، لن يُصلَح، مكرر، يعمل لديّ) والانتقالات — كمثال عملي لدورة الحياة.
• ISO/IEC/IEEE 29119-3:2021 — Software and systems engineering — Software testing — Part 3: Test documentationISO/IEC/IEEE · 2021نماذج ومحتوى وثائق الاختبار — سياسة الاختبار واستراتيجيته وخطته وتقارير الحالة والإنجاز وتقارير الحوادث.
• Certified Tester Advanced Level Test Management (CTAL-TM) v3.0ISTQB · 2024منهج ISTQB المتقدم لإدارة الاختبار: التخطيط والتقدير، والاختبار المبني على المخاطر، والمتابعة، والمقاييس والتقارير.