فرز العيوب (Defect Triage)

الغرض والمشاركون

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

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

الإيقاع وشكل الاجتماع

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

يمكن إنجاز كثير من العمل قبل الاجتماع. يفحص قائد الجودة البلاغات الجديدة مسبقاً من حيث الاكتمال والتكرار، ويعيد الناقص منها إلى «بحاجة إلى معلومات»، فتقضي الجلسة وقتها في القرارات لا في القراءة.

جدول الجلسة في المثال أدناه (20 دقيقة يومياً أثناء تثبيت الإصدار): الدقيقتان الأوليان لفحص الطابور — عدد العيوب في «جديد»، وأقدم عيب غير مفروز، وأي عيب Blocker أو Critical منذ الجلسة السابقة؛ ومن الدقيقة 2 إلى 15 العيوب الجديدة، الأعلى في الخطورة المقترحة أولاً، بدقيقة أو دقيقتين لكل عيب، يعرضها المبلِّغ أو قائد الجودة من سجل العيب نفسه لا من شريحة عرض؛ ومن 15 إلى 18 البنود المتقادمة أو المتنازع عليها: ما بقي في «بحاجة إلى معلومات» أكثر من 3 أيام، والمؤجل الذي حان موعد مراجعته، وخلافات إعادة الفتح؛ ومن 18 إلى 20 تُقرأ القرارات ويؤكدها كل مالك. والقاعدة: كل ما يحتاج إلى أكثر من دقيقتين يخرج من الجلسة بمالك وسؤال مكتوب.

• سجّل القرارات في المتتبّع أثناء الجلسة، لا في محضر الاجتماع أو المحادثة.
• أبقِ المجموعة صغيرة: من يستطيعون القرار، لا كل المهتمين.
• قِس العملية: عدد غير المفروز، وعمر أقدم عيب غير مفروز، والزمن من «جديد» حتى القرار.

Defect triage - 20 minutes, daily during release hardening

00-02  Queue check: number of New, oldest untriaged, any Blocker/Critical since last session
02-15  New defects, highest proposed severity first, 1-2 minutes each
       Presenter: reporter or QA lead. On screen: the defect record, not a slide.
15-18  Aged or disputed items: Needs info > 3 days, Deferred due for review, reopen disputes
18-20  Read back decisions; each owner confirms

Rule: anything that needs more than 2 minutes leaves with an owner and a written question.

قائمة تحقق الفرز

مرّر كل عيب جديد على الأسئلة نفسها بالترتيب نفسه. السؤالان الأولان بوابتان: إن لم يمكن إعادة إنتاج العيب أو تقديم دليل عليه، أو كان البلاغ ناقصاً، ينتقل إلى «بحاجة إلى معلومات» مع سؤال محدد ولا يبقى في «جديد».

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

[ ] Reproducible?   Steps run by someone other than the reporter, or evidence strong enough for an
                    intermittent failure (logs, request id, timestamps, recording)
[ ] Complete?       Build, environment, account/role, data, expected vs actual
[ ] Duplicate?      Searched by error text, endpoint or screen, component; linked if found
[ ] Valid?          Expected result traced to a requirement, design or clear convention
[ ] Severity        Impact on user/system on the agreed scale (Blocker ... Trivial)
[ ] Priority        Business urgency (Highest ... Low): release date, users affected, visibility
[ ] Owner           A named person, or a team queue with a named lead - not "dev team"
[ ] Target release  Version or sprint; or Deferred with reason; or Won't fix with reason
[ ] Workaround      Exists? Written down for support and the release notes
[ ] Info needed     The exact missing item and who must provide it
[ ] Links           Story/requirement, test case, related defects, incident (if production)

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

الخطورة × الأولوية: مصفوفة قرار

يعرّف دليل كتابة تقرير الخطأ السُّلّمين: الخطورة (Severity) بمستويات Blocker وCritical وMajor وMinor وTrivial؛ والأولوية (Priority) بمستويات Highest وHigh وMedium وLow. الخطورة أثر والأولوية إلحاح، لذا فكل تركيبة ممكنة. تعطي المصفوفة أدناه قرارات نموذجية مع أمثلة؛ وهي نقطة بداية للنقاش لا معادلة — يحق لمالك المنتج تحريك الأولوية، لكن السبب يُسجَّل.

أمثلة المصفوفة وقراراتها النموذجية: Blocker × Highest: تسجيل الدخول يعيد الخطأ 500 لكل المستخدمين في الإنتاج — إصلاح عاجل (Hotfix) الآن مع فتح حادثة. Critical × Highest: صفحة الدفع تحتسب مبلغ ضريبة القيمة المضافة خطأً والإصدار بعد 7 أيام — يُصلَح قبل الإصدار ويوقف اعتماده. Critical × Low: تصدير إداري ربع سنوي يُسقط صفوفاً وتشغيله التالي بعد 10 أسابيع — يُجدوَل مع تحديد تاريخ للمراجعة. Major × High: قائمة الطلبات تتجاهل مرشّح التاريخ، والحل البديل هو الترتيب — يُصلَح في هذا الإصدار. Major × Medium: الاستيراد الجماعي لملف يزيد على 5 MB يفشل دون رسالة، وهو نادر — في السبرنت التالي. Minor × High: رسالة خطأ عربية تعرض عنصراً نائباً إنجليزياً في حقل الهوية الوطنية بنموذج التسجيل — يُصلَح قبل حملة إطلاق. Minor × Low: تلميح مقصوص عند عرض 320 px في الواجهة العربية — قائمة الانتظار. Trivial × High: اسم الشركة مكتوب خطأً في صفحة تسجيل الدخول — إصلاح سريع لأنه ظاهر للجميع. Trivial × Low: مسافة زائدة في سطر حقوق النشر في التذييل — قائمة الانتظار، ويُجمَع مع إصلاحات النصوص الأخرى.

• العيب من مستوى Blocker أو Critical بأولوية Low يحتاج إلى سبب مكتوب: الميزة معطّلة، أو الموعد بعيد، أو لا يستطيع أي مستخدم الوصول إليه.
• مستوى Trivial أو Minor بأولوية High أو Highest يتعلق عادةً بالظهور: نص قانوني، أو العلامة التجارية، أو عرض توضيحي، أو شاشة سيراها منظِّم أو عميل رئيسي.
• لا تُخفَّض الأولوية لاجتياز معيار خروج؛ ولا تُغيَّر الخطورة دون دليل جديد.
• تعبّر أداة AI Bug Priority Suggestion عن اقتراحها بسُلّم P0–P3، من P0 (إصلاح فوري) إلى P3 (قائمة الانتظار). احتفظ بجدول مكتوب يربطه بمتتبّعك — مثلاً P0 ← Highest، وP1 ← High، وP2 ← Medium، وP3 ← Low.

Severity x Priority   Example defect                                          Typical decision
--------------------  ------------------------------------------------------  ------------------------------
Blocker  x Highest    Login returns 500 for every user in production          Hotfix now, incident open
Critical x Highest    Checkout charges the wrong VAT amount, release in 7 d   Fix before release; blocks sign-off
Critical x Low        Quarterly admin export drops rows; next run: 10 weeks   Schedule; set a review date
Major    x High       Orders list ignores date filter; workaround: sort       Fix in this release
Major    x Medium     Bulk import over 5 MB fails with no message; rare       Next sprint
Minor    x High       Arabic error text shows an English placeholder on the   Fix before a launch campaign
                      national ID field of the sign-up form
Minor    x Low        Tooltip clipped at 320 px width in the Arabic layout    Backlog
Trivial  x High       Company name misspelled on the login page               Quick fix; high visibility
Trivial  x Low        Extra space in the footer copyright line                Backlog; batch with copy fixes

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

الإسناد والتحقيق

أسنِد حسب الملكية لا حسب من يصادف وجوده في الاجتماع: مالك المكوّن أو الخدمة، أو طابور فريق له قائد مسمّى يوزّع العمل خلال يوم. العيب المُسنَد إلى «الفريق» بلا مالك. وعندما يمكن أن يقع السبب في عدة طبقات — التطبيق أو API أو البيانات — أسنِده إلى الطبقة التي لوحظ فيها الإخفاق، ودع مالكها يمرّره بالأدلة، بدلاً من إبقائه في الفرز حتى يخمّن أحدهم الإجابة الصحيحة.

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

• أعد الإنتاج ببيانات المبلِّغ وفي بيئته أولاً، ثم محلياً.
• جد آخر بناء سليم وضيّق نطاق التغييرات؛ ومع git استخدم bisect على الإيداعات (Commits) بينهما.
• قارن حالة ناجحة بحالة فاشلة — الويب مقابل Android، أو حساباً مقابل آخر — على مستوى الطلب: التقط الطلبين وقارن الاستجابتين.
• اقرأ تتبّع المكدس (Stack trace) بدءاً من أول إطار في شيفرتك؛ وافحص الإعدادات وأعلام الميزات والبيانات قبل تغيير الشيفرة.
• اكتب النتائج في سجل العيب لا في المحادثة فقط، حتى لا يبدأ الشخص التالي من الصفر.

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

تحليل السبب الجذري: لماذا الخمسة وعظمة السمكة والأصل

الإصلاح يزيل عيباً واحداً؛ أما تحليل السبب الجذري (Root cause analysis) فيسأل لماذا وقع الخطأ ولماذا لم يُكتشف مبكراً، لمنع الفئة نفسها من العيوب. ويفصل منهج ISTQB التأسيسي بين السبب الجذري والعيب والإخفاق الذي يسببه. أجرِ تحليل السبب الجذري لعيوب Blocker وCritical، وللعيوب التي أفلتت إلى الإنتاج، وللأنماط المتكررة — لا لكل خطأ إملائي.

تقنية لماذا الخمسة (5 Whys) تطرح «لماذا؟» مراراً بدءاً من الإخفاق حتى تصل الإجابة إلى سبب في العملية يستطيع الفريق تغييره. والرقم خمسة قاعدة استرشادية لا قاعدة ملزمة؛ توقف عندما تصبح الإجابة قابلة للتنفيذ، وتفرّع عندما يكون للإجابة الواحدة عدة أسباب. ومخطط عظمة السمكة (Fishbone / Ishikawa) يعرض الأسباب المحتملة حسب الفئات حتى لا يتعلق النقاش بأول سبب معقول. وفي البرمجيات، الفئات المفيدة هي فئات الأصل أدناه نفسها، مضافاً إليها الأشخاص والعملية.

صنّف كل عيب حسب مكان نشوئه. يعرّف معيار IEEE 1044 مجموعة أغنى بكثير من السمات لتصنيف الشذوذات؛ أما الأصول الستة أدناه فنقطة بداية بسيطة يستطيع معظم الفرق تطبيقها باتساق أثناء الفرز.

• المتطلبات (Requirements) — متطلب ناقص أو غامض أو خاطئ، أو تغيّر دون أن يصل التغيير إلى كل من يستخدمه.
• التصميم (Design) — قرار معماري أو قرار واجهة خاطئ أو غير متسق.
• الشيفرة (Code) — خطأ في التنفيذ: المنطق، أو الحدود، أو التعامل مع القيم الفارغة، أو التزامن، أو منطق مكرر.
• البيئة (Environment) — الإعدادات، أو البنية التحتية، أو الإصدارات، أو خدمة طرف ثالث، أو النشر.
• البيانات (Data) — بيانات غير متوقعة أو مشوّهة أو مُرحَّلة بشكل سيئ؛ أو بيانات مرجعية خاطئة.
• الاختبار (Test) — العيب في الاختبار نفسه (إيجابية كاذبة)، أو فجوة في الاختبار سمحت بإفلاته؛ سجّل فجوات الاختبار كأسباب مساهمة.

مثال تطبيقي: السبب الجذري لعيب في ضريبة القيمة المضافة

مثال افتراضي يكمل العيب الذي تتبّعناه في دليل دورة حياة العيب: عملية الدفع في تطبيق Android تقاضت 190.00 ريالاً بدلاً من 184.00 عند تطبيق قسيمة بمبلغ ثابت، لأن ضريبة القيمة المضافة حُسبت قبل الخصم.

سلسلة «لماذا» في المثال أدناه: لماذا كان المبلغ خاطئاً؟ لأن التسعير في API v2 طبّق القسيمة بعد احتساب ضريبة 15%. ولماذا؟ لأن لـ v2 نسخته الخاصة من دالة التسعير، متفرعة من v1. ولماذا لم تُحدَّث النسخة؟ لأن قاعدة «الضريبة على السعر بعد الخصم» (الإصدار 5.1) كُتبت قصةً لصفحة الدفع على الويب وحدها، ولم يُحصِ أحد المستهلكين الآخرين للتسعير. ولماذا لم تكشفه الاختبارات؟ لأن اختبارات API v2 لم تتضمن حالات قسائم، ولا بيانات الاختبار. ولماذا غابت حالة القسيمة؟ لأن اختبارات v2 نُسخت من حالات المسار الناجح في v1 ولم تُراجَع مقابل جدول قرار التسعير. التصنيف: الأصل الأساسي في المتطلبات، مع أسباب مساهمة في الشيفرة والاختبار؛ والإجراءات، لكل منها مالك وموعد: خدمة تسعير واحدة يستخدمها v1 وv2 والويب، واختبارات API مبنية على جدول قرار (نوع القسيمة × الضريبة × التقريب)، وسؤال جديد في قالب القصة: «ما العملاء أو واجهات API التي تستخدم هذه القاعدة؟».

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

DEF-2417  Android checkout charges 190.00 SAR instead of 184.00 with a fixed-amount coupon

5 whys
1  Why was the amount wrong?       API v2 pricing applied the coupon after calculating 15% VAT.
2  Why did v2 do that?             v2 has its own copy of the pricing function, forked from v1.
3  Why was the copy not updated?   The rule "VAT on the discounted price" (release 5.1) was written
                                   as a story for web checkout only; no one listed the other
                                   consumers of pricing.
4  Why did tests not catch it?     v2 API tests had no coupon cases; the test data had no coupons.
5  Why was there no coupon case?   v2 tests were copied from v1 happy-path cases and never reviewed
                                   against the pricing decision table.

Fishbone (contributing causes)
  Requirements  rule change scoped to one client
  Design        pricing logic duplicated per API version
  Code          order of operations in v2 price() and summary()
  Test          no coupon x VAT combinations at API level; test data without coupons
  Environment   none (reproduced on staging and locally)
  Data          none

Classification  origin: requirements (primary); code, test (contributing)
Actions (owner, due)
  - One pricing service used by v1, v2 and web              (omar.k, release 5.4)
  - Decision-table API tests: coupon type x VAT x rounding  (layla.h, 2026-09-25)
  - Story template asks "Which clients or APIs use this rule?" (product owner, next refinement)

أنماط خاطئة في الفرز

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

ما الذي ينتجه الفرز

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

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

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

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

المراجع

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• ISTQB GlossaryISTQBالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
• Certified Tester Advanced Level Test Management (CTAL-TM) v3.0ISTQB · 2024منهج ISTQB المتقدم لإدارة الاختبار: التخطيط والتقدير، والاختبار المبني على المخاطر، والمتابعة، والمقاييس والتقارير.
• 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)سير العمل الافتراضي للأخطاء في متتبّع واسع الاستخدام — الحالات والقرارات (مُصلَح، غير صالح، لن يُصلَح، مكرر، يعمل لديّ) والانتقالات — كمثال عملي لدورة الحياة.
• Lessons Learned in Software Testing: A Context-Driven Approach (Cem Kaner, James Bach, Bret Pettichord)Wiley · 2001دروس عملية في الإبلاغ عن الأخطاء وتصميم الاختبارات والأتمتة وإدارة الاختبار — مدرسة الاختبار المدفوع بالسياق.