Severity و Priority — شو الفرق؟ (مع أمثلة من مشاريع حقيقية)
الفرق بين Severity و Priority بالعربي، مصفوفة الحالات الأربع بأمثلة من مشاريع حقيقية، ومين يحدّد كل واحد منهم — وأشهر الأخطاء بالتعبئة.
«هذا الـ Bug خطير ولا مستعجل؟» — سؤال بسيط بالشكل، بس أغلب المختبرين الجدد بيجاوبوا عليه بحقل واحد. والنتيجة إنّه الـ Bugs تُرتّب غلط: Bug بشع بشاشة ما بيفتحها حدا بياخد وقت الفريق، وBug صغير بشاشة الدفع بيضلّ مفتوح لآخر Sprint.
Severity و Priority حقلين مختلفين، وبيتعبّوا من ناس مختلفة، ولأسباب مختلفة. هذا المقال بيوضّح الفرق بجملة، بمصفوفة، وبأمثلة عملية.
الاثنين بجملة
Severity — درجة الخطورة
قد إيش الـ Bug مؤذي تقنياً لما يصير. بتوصف الأثر على النظام: هل بيوقف وظيفة كاملة؟ بيخرّب بيانات؟ بيطيّح التطبيق؟ ولا مجرّد شكل مش مضبوط؟
Severity حقل تقني وموضوعي نسبياً، وبيعبّيه المختبر — لأنّه هو اللي شاف الأثر بعينه.
Priority — درجة الأولوية
قد إيش إصلاحه مستعجل بالنسبة للشغل. بتوصف ترتيب الإصلاح بالوقت: هل لازم ينصلح قبل الإصدار؟ هذا الـ Sprint؟ ولا فيه مجال يستنّى؟
Priority حقل تجاري/إداري، وبيعبّيه (أو بيعدّله) Product Owner أو مدير المشروع بالتنسيق مع الفريق — لأنّه القرار مربوط بالعميل، بالعقد، وبتاريخ الإصدار.
القاعدة اللي بتثبّت الفرق: Severity بتوصف الـ Bug، Priority بتوصف قرارنا تجاهه.
جدول المقارنة
| Severity | Priority | |
|---|---|---|
| بتقيس | الأثر التقني | استعجال الإصلاح |
| بتجاوب على | شو حجم الضرر؟ | إيمتى لازم ينصلح؟ |
| مين بيعبّيها | المختبر | Product Owner / مدير المشروع |
| بتتغيّر مع الوقت | نادراً | كثير — حسب الإصدار والعميل |
| مرجعها | سلوك النظام | خطة العمل والأولويات |
| مثال قيم | Critical / Major / Minor / Cosmetic | Highest / High / Medium / Low |
المصفوفة: أربع حالات، وكل واحدة إلها معنى
| Priority عالية | Priority منخفضة | |
|---|---|---|
| Severity عالية | تطبيق يطيح عند تسجيل الدخول — كل المستخدمين واقفين | تطبيق يطيح بشاشة إعدادات قديمة رح تُحذف بالإصدار الجاي |
| Severity منخفضة | اسم الشركة مكتوب غلط على صفحة الدفع — الأثر تقني بسيط، بس الضرر على الصورة كبير | لون زر بصفحة داخلية أفتح من التصميم بـ 5% |
الحالتين المائلتين (عالية/منخفضة) هي اللي بتفرّق المختبر المحترف: هو مين بيعرف إنّ Bug «صغير» تقنياً ممكن يكون أخطر شي على العميل، والعكس.
أمثلة من مشاريع حقيقية
1) تطبيق موبايل لعرض العقارات
المستخدم يرفع 12 صورة لعقار، فيطيح التطبيق (crash) على أجهزة Android بذاكرة منخفضة.
- Severity: Critical — التطبيق بيطيح وبتضيع البيانات المُدخلة.
- Priority: High — رفع العقار هو الوظيفة الأساسية بالتطبيق، والمُلاك هدول أهم مستخدمين.
2) بوابة ويب للمستثمرين
بصفحة «التقارير»، عمود التاريخ ظاهر بصيغة MM/DD/YYYY بدل DD/MM/YYYY.
- Severity: Minor — الصفحة تشتغل، والبيانات صح، بس الصيغة مضلّلة.
- Priority: Highest — العميل بيقرأ هذا التقرير بجلسة مع مستثمرين بعد يومين، وقراءة تاريخ غلط بتعني قرار غلط.
هنا بالضبط ليش الحقلين لازم يكونوا منفصلين: لو عندك حقل واحد، هذا الـ Bug إمّا بينزل بالترتيب (بحكم إنّه Minor) أو بتضطر تكذب وتكتب Severity أعلى من الحقيقة.
3) موقع فيه صفحة «من نحن»
خطأ إملائي باسم المدينة بآخر الصفحة.
- Severity: Cosmetic.
- Priority: Low — يُجمّع مع باقي التعديلات النصّية بدفعة واحدة.
أشهر خمسة أخطاء بتعبئة الحقلين
- تعبئة الحقلين بنفس القيمة دايماً. إذا كل Bugsك Severity = Priority، فأحد الحقلين ما إله قيمة عندك — والمصفوفة فوق ما بتُستخدم.
- المختبر يرفع Severity مشان يستعجل الإصلاح. هذا بيضيّع الثقة بأرقامك، ولمّا يصير Bug حقيقي Critical محدا بياخده بجدية. لو بدك تستعجل، الطريق الصح إنّك توضّح الأثر على العمل بوصف الـ bug report وتخلّي Priority قرار صاحب القرار.
- الخلط بين Priority و«إلحاح المستخدم». عميل زعلان مش نفس شي إنّه الـ Bug أولوية — الأولوية بتتحدّد بأثر مالي/تعاقدي/سُمعة، مش بنبرة الرسالة.
- ترك Priority فاضية بحجّة «مش شغلي». اكتب اقتراحك، وخلّي التعديل النهائي لـ Product Owner. اقتراح مبنيّ على أثر واضح قيمته عالية.
- إهمال الـ Bugs Blocker. إذا الـ Bug مانع باقي الاختبار (مش مانع المستخدم بس)، لازم تقول هذا صريح بالتقرير — لأنّه بيوقف خطة الاختبار كلها، وهذا Priority عالية بغضّ النظر عن Severity.
قيم عملية تنفع تتبنّاها
Severity:
- Critical / Blocker: النظام أو وظيفة رئيسية واقفة، أو فيه فقدان/تلف بيانات، ولا يوجد حل بديل.
- Major: وظيفة مهمة مكسورة، بس فيه حل بديل (workaround).
- Minor: سلوك غلط بس بيقدر المستخدم يكمّل شغله.
- Cosmetic: شكل، محاذاة، نص، أيقونة — بلا أثر وظيفي.
Priority:
- Highest: يوقف الإصدار — ينصلح اليوم.
- High: لازم يخلص هذا الـ Sprint.
- Medium: يُجدول بالـ Backlog القريب.
- Low: يُجمّع مع دفعة تعديلات لاحقة.
على Jira: وين بالضبط
بمشاريع Jira، Priority حقل جاهز افتراضياً، أما Severity فعادة بتُضاف كحقل مخصّص (Custom Field) — إذا مشروعك ما فيه Severity، هذا سبب شائع لكل الخلط. حلّين:
- اطلب إضافة حقل Severity من مدير Jira، وخلّي الحقلين إلزاميين على نوع الـ Bug.
- لو ما توفّر، وثّق الخطورة بأول سطر بالوصف («الأثر: التطبيق يطيح وتضيع البيانات») واستخدم Priority للترتيب — بس اتفق مع الفريق على القاعدة، لتفضل مفهومة للكل.
وإذا لسا ما تعرف تدير الـ issues على Jira منيح، ابدأ من دورة Jira من الصفر للاحتراف.
ليش هذا الفرق مهم عملياً؟
- بيحمي وقت الفريق: الترتيب الصح بيخلّي الإصلاح يمشي على الأخطر والأهم أول.
- بيحمي مصداقيّتك: أرقامك تفضل موثوقة، وكلمتك تفضل مسموعة بجلسة تحديد الأولويات.
- بيخلّي القرار واضح: تقرير الجودة قبل الإصدار بيصير جملة واحدة مفهومة: «ما ضلّ ولا Bug Critical مفتوح، وضلّ ثلاثة Minor بأولوية Low».
أسئلة شائعة
مين المسؤول عن Severity؟ المختبر. هو شاف الأثر، وبيوصفه تقنياً بلا تدخّل بقرار الجدولة.
مين المسؤول عن Priority؟ Product Owner أو مدير المشروع. المختبر بيقترح، وصاحب القرار بيثبّت.
ممكن Severity عالية و Priority منخفضة بنفس الوقت؟ نعم، وهذا طبيعي — مثلاً Bug خطير بميزة رح تُشال من المنتج بالإصدار الجاي.
هل Blocker نوع Severity ولا Priority؟ بأغلب الأدوات هي قيمة داخل Severity (أو Priority بأدوات ثانية). المهم إنّ الفريق يتفق على معناها: «مانع للاختبار أو للاستخدام، ولا يوجد بديل».
هذا الفرق بيتسأل بامتحان ISTQB؟ نعم، وبيتسأل كثير بالمقابلات كمان — راجع أسئلة مقابلة QA و دورة ISTQB CTFL V4.
خطوتك الجاية
- اتعلّم تكتب الـ Bug نفسه صح: كيف تكتب Bug Report ما يرجعلك.
- افهم مسار الـ Bug من فتحه لإغلاقه: دورة حياة الـ Bug.
- الأساسيات كاملة بالعربي: دورة ISTQB CTFL V4.
النقاش 🔻