مرحبا ويعطيكم العافية وأهلا وسهلا فيكم في درس جديد من سلسلة اختبار البرمجيات!
كمختبر، أكيد شفت Bug وحسيت إنه "خطير" أو "مهم" أو "لازم يتصلح فوراً!" لكن وقت تريد أن تسجله بالـ Bug Tracking System، تجد خانتين: Severity و Priority.
كثير مختبرين - حتى اللي عندهم خبرة - يستخدموا المصطلحين هذول وكأنهم نفس الشي. يحطوا High Severity وHigh Priority لكل Bug يحسوا إنه كبير. لكن الحقيقة؟
Severity و Priority هم مختلفين تماماً!
والأهم من هيك - فهم الفرق بينهم مش فقط مصطلحات... هذا جزء أساسي من شغلك كمختبر محترف.
بنهاية هذا الدرس، ستكون قادراً على:
Severity تجاوب على سؤال واحد: كم هذه المشكلة خطيرة تقنياً على النظام؟
يعني: كم التأثير التقني على النظام والمستخدم؟ كم الـ Bug كبير من ناحية الـ Functionality؟
الـ Severity هي مقياس تقني بحت. مش لها علاقة بالبزنس أو الوقت أو العملاء - لكن التأثير على النظام.
المختبر (Tester) أو الفريق التقني هم الذين يحددوا الـ Severity.
ليش؟ لأنه المختبر هو الذي فاهم التأثير التقني للمشكلة. هو الذي يعرف:
المستويات تختلف من شركة لشركة، لكن عادةً تكون هيك:
مثال واقعي: تطبيق بنك والـ Login مش شغال - ما أحد أستطيع يدخل!
مثال واقعي: Instagram - زر "Upload Photo" مش شغال من الـ App، لكن شغال من الـ Browser.
مثال واقعي: Netflix - الـ Subtitles بلغة معينة مش ظاهرة بشكل صحيح، لكن باقي اللغات شغالة.
مثال واقعي: Amazon - اسم منتج فيه Typo بصفحة "About Us".
Priority تجاوب على سؤال مختلف تماماً: كم مستعجلين نصلح هذه المشكلة؟
يعني: من ناحية البزنس، هل لازم نصلحها اليوم؟ ولا ممكن نأجلها للـ Sprint الجاي؟
الـ Priority هي مقياس بزنس. تعتمد على: أهمية الميزة للشركة، عدد المستخدمين المتأثرين، الوقت، السمعة، الربح.
Product Owner / Product Manager / Business Team هم الذين يحددوا الـ Priority.
ليش؟ لأنهم هم الذين فاهمين:
برضه تختلف من شركة لشركة، لكن عادةً:
| Severity | Priority |
|---|---|
| كم المشكلة كبيرة؟ (تقني) | كم مستعجلين نصلحها؟ (بزنس) |
| How bad is the bug? | How soon should we fix it? |
| يحددها ← المختبر / الفريق التقني | يحددها ← Product Owner / البزنس |
| تعتمد على ← التأثير التقني | تعتمد على ← الأهمية للبزنس والوقت |
خلينا نشوف أمثلة من تطبيقات حقيقية حتى الموضوع يصير واضح 100%.
السيناريو: Amazon - زر "Delete Account" مش شغال.
Severity: High
ليش؟ لأنه ميزة كاملة مش شغالة! من الناحية التقنية، هذا Bug كبير.
Priority: Low
ليش؟ لأنه قليل جداً من الناس بيحذفوا حساباتهم. الميزة مش مهمة للبزنس حالياً. ممكن ننتظر للـ Sprint الجاي.
هذا المثال يوضح إنه مش كل Bug خطير لازم ينصلح فوراً! البزنس يقرر.
السيناريو: Amazon - الـ Logo تبع الشركة غلط أو مكسور بصفحة الـ Homepage.
Severity: Low
ليش؟ لأنه مشكلة تجميلية. لا يوجد functionality مكسور. الناس بقدروا يتسوقوا عادي.
Priority: High - Urgent!
ليش؟ لأنه ملايين الناس يشوفوا الـ Homepage كل يوم! الـ Logo الغلط يأثر على سمعة Amazon. لازم يتصلح فوراً!
السيناريو: تطبيق بنك - نظام الـ Payment والتحويلات واقف.
Severity: Critical
ليش؟ لأنه النظام بالكامل مش شغال! الناس ما بقدروا يحولوا فلوس أو يدفعوا فواتير.
Priority: Urgent
ليش؟ لأنه البنك عم بيخسر ملايين الدولارات كل ساعة! العملاء زعلانين! السمعة بخطر! لازم يتصلح الآن!
هذا السيناريو الوحيد الذي Severity و Priority يكونوا نفس المستوى - وهذا نادر!
السيناريو: Netflix - Typo (خطأ إملائي) بصفحة "About Us".
Severity: Low
ليش؟ لأنه خطأ إملائي. ما يأثر على الـ Functionality أبداً.
Priority: Low
ليش؟ لأنه قليل جداً من الناس بيدخلوا على صفحة "About Us". مش مهم للبزنس. ممكن ينصلح عندما يكون في وقت.
السيناريو: Instagram - الـ Filters الجديدة التي أطلقوها امبارح مش شغالة على بعض الموبايلات.
Severity: Medium
ليش؟ لأنه الـ Filters القديمة شغالة. الناس بقدروا يستخدموا التطبيق عادي. لكن الـ Feature الجديدة فيها مشكلة.
Priority: High
ليش؟ لأنه Instagram أعلنوا عن الـ Filters الجديدة! الناس متحمسين ليها! لو ما اشتغلت، سيكون في ردود فعل سلبية. لازم تتصلح بسرعة.
| العنصر | Severity (الخطورة) | Priority (الأولوية) |
|---|---|---|
| التعريف | كم المشكلة خطيرة تقنياً؟ | كم مستعجلين نصلحها؟ |
| النوع | تقني (Technical) | بزنس (Business) |
| من بيحددها؟ | Tester / QA Team | Product Owner / Manager |
| تعتمد على؟ | التأثير على النظام والـ Functionality | الأهمية للبزنس، الوقت، العملاء، الفلوس |
| تتغيّر؟ | نادراً (التأثير التقني ثابت) | كثير! (حسب الوقت والظروف) |
| أمثلة العوامل | النظام واقف؟ في workaround؟ Data loss؟ | كم ناس متأثرين؟ سنخسر فلوس؟ سمعة الشركة؟ |
كثير مختبرين يحطوا نفس القيمة للـ Severity والـ Priority. يفكروا: "هذا Bug كبير، يعني High Severity و High Priority!"
الغلط: Severity و Priority مستقلين عن بعض! ممكن يكونوا مختلفين تماماً.
كثير مختبرين بيفترضوا إنه كل Bug خطير لازم يتصلح فوراً.
الواقع: البزنس يقرر متى يتصلح. Bug خطير تقنياً لكن يخص ميزة قليل ناس يستخدموها؟ ممكن ينأجل.
بعض المختبرين يزعلوا عندما الـ Product Owner يحط Priority واطية لـ Bug خطير.
الحقيقة: الـ Priority مش شغلة المختبر. شغلة المختبر يوضح التأثير التقني (Severity)، والبزنس يقرر الأولوية.
كثير مختبرين يحطوا Severity دون أن يوضحوا ليش.
الأفضل: اكتب بالـ Bug Description ليش اخترت هذا الـ Severity. وضّح التأثير. هيك الكل يفهم ولن يكون في خلافات.
لا تخلي البزنس يأثر على حكمك التقني. لو الـ Bug خطير تقنياً، حط High Severity - حتى لو الميزة مش مهمة للبزنس.
مش شغلتك تحدد الأولوية. وضّح التأثير التقني بوضوح، والبزنس يقرر متى يتصلح.
اكتب بالـ Bug:
هيك القرار يصير واضح للكل.
لو الـ Product Owner حط Priority واطية لـ Bug خطير:
البزنس عنده معلومات لا تملك إياها: ميزانيات، عملاء، مواعيد، استراتيجيات. ثق بقرارهم.
الـ Severity ثابتة - التأثير التقني ثابت.
لكن الـ Priority ممكن تتغير! Bug كان Low Priority ممكن يصير High Priority لو:
هذا طبيعي! البزنس ديناميكي.
بالتوفيق، ونشوفكم بالدرس الجاي! 🚀