كيف تكتب Bug Report ما يرجعلك!
دليل عملي بالعربي لكتابة Bug Report واضح ومقنع: عناصره الكاملة، صياغة العنوان، الفرق بين الشدة والأولوية، قالب جاهز، وأسباب رجوع التقارير.

في فرق كثيرة، أكثر شي بيوقف شغل المختبر مش اكتشاف الـ Bugs — رجوع التقارير. تقرير بيرجع بـ «ما قدرت أعيد إنتاجه» أو «هذا مش Bug» يعني وقت مهدور من الطرفين، وثقة أقل بشغلك.
الخبر الحلو إنّ 90% من هذي المشاكل سببها صياغة، مش تقنية. هذا الدليل بيعطيك القالب والقواعد اللي بتخلّي تقريرك واضح ومقنع من أوّل قراءة.
ليش بيرجع تقرير الـ Bug؟
- عنوان غامض مثل «التطبيق ما بيشتغل» — ما بيقول شو صار ولا وين.
- خطوات ناقصة أو بتفترض إنّ المطوّر عارف حالة البيانات اللي عندك.
- ما في فرق واضح بين النتيجة الفعلية والنتيجة المتوقّعة.
- بيئة مجهولة: أي جهاز، أي إصدار، أي حساب، أي بيئة (تجريبية ولا إنتاج).
- تخمين للسبب بدل وصف السلوك — فيتحوّل النقاش من الـ Bug لصحّة تحليلك.
عناصر التقرير الكامل
| العنصر | ليش مهم |
|---|---|
| العنوان | بيتقرأ بالليستة، وبيحدّد إذا التكت بتُفتح أصلاً |
| البيئة | الجهاز، نظام التشغيل، إصدار التطبيق أو المتصفّح، البيئة والحساب |
| المتطلّبات المسبقة | حالة البيانات اللازمة قبل الخطوات (حساب فيه رصيد، سلّة فاضية…) |
| خطوات إعادة الإنتاج | مرقّمة، وكل خطوة إجراء واحد |
| النتيجة الفعلية | اللي شفته بالواجهة بالضبط، ونصّ رسالة الخطأ إذا ظهرت |
| النتيجة المتوقّعة | اللي المفروض يصير، ومن وين جبت هذا التوقّع (متطلب، تصميم، معيار قبول) |
| الشدة والأولوية | حقلين مختلفين — تحت بنفرّقهم |
| المرفقات | صورة أو فيديو قصير، ووقت الحدوث |
كيف تكتب عنوان محترم
استخدم هذي الصيغة:
[الشاشة أو الميزة] — السلوك الملحوظ عند شرط معيّن
قبل: «مشكلة بالدفع» بعد: «شاشة الدفع — المبلغ الإجمالي بيظهر بدون الضريبة عند اختيار الدفع عند الاستلام»
قبل: «التطبيق بيطلع» بعد: «شاشة السلّة — التطبيق بيغلق عند إضافة أكثر من 10 عناصر على iPhone 12 / iOS 17»
العنوان الجيد بيخلّي المطوّر يفهم الـ Bug بلا ما يفتح التكت.
خطوات إعادة الإنتاج: 5 قواعد
- ابدأ من نقطة صفر معروفة: «افتح التطبيق وسجّل دخول بحساب…».
- خطوة واحدة = إجراء واحد، وبالترقيم.
- اكتب البيانات الفعلية اللي استخدمتها (المبلغ، الرقم، اسم المستخدم التجريبي).
- حدّد نقطة الفشل بوضوح: عند أي خطوة ظهر السلوك.
- جرّبها مرّتين قبل ما ترسل — إذا ما تكرّر، اكتب إنّه متقطّع (intermittent) ونسبة تكراره.
الشدة مقابل الأولوية
- الشدة (Severity): قدّ إيش أثر الـ Bug على المنتج تقنياً ووظيفياً — يقرّرها المختبر.
- الأولوية (Priority): قدّ إيش لازم يُصلَح بسرعة من ناحية العمل — قرار الـ Product Owner غالباً.
| أولوية عالية | أولوية منخفضة | |
|---|---|---|
| شدة عالية | الدفع بيفشل لكل المستخدمين | ميزة بتطيح، بس بشاشة ما حدا بيستخدمها |
| شدة منخفضة | خطأ إملائي باسم الشركة على الشاشة الرئيسية | لون زر مختلف بشاشة داخلية |
الخلط بينهم أشهر سبب لجدال بلا فايدة بالـ Sprint.
قاعدة ذهبية: صف اللي بتشوفه، مش اللي بتتوقّعه صار
اكتب السلوك الملحوظ من الواجهة، بلا تخمين للسبب. «الطلب ما ظهر بالقائمة» أفضل من «في مشكلة بالسيرفر» — لأنك بتوصف حقيقة، والتحليل شغل المطوّر. وهذا بيقلّل النقاش ويقصّر الطريق للإصلاح.
قالب جاهز
العنوان: [الشاشة] — السلوك الملحوظ عند [الشرط]
البيئة:
- الجهاز / المتصفّح:
- نظام التشغيل:
- إصدار التطبيق:
- البيئة (تجريبية / إنتاج) والحساب:
المتطلّبات المسبقة:
-
خطوات إعادة الإنتاج:
1.
2.
3.
النتيجة الفعلية:
النتيجة المتوقّعة:
المصدر (متطلب / تصميم / معيار قبول):
الشدة: الأولوية:
التكرار: دائم / متقطّع (…/10)
المرفقات: صورة / فيديو / وقت الحدوث
قبل ما تضغط Create: 7 نقاط
- العنوان يفهمه حدا ما جرّب الـ Bug.
- الخطوات مرقّمة وبتبدأ من نقطة معروفة.
- البيانات الفعلية مكتوبة.
- الفعلي والمتوقّع مفصولين بوضوح.
- مرفق واحد على الأقل (صورة أو فيديو).
- الشدة والأولوية معبّيات، وسبب الشدة واضح.
- بحثت إذا التكت مكرّر قبل ما تفتح واحد جديد.
أخطاء شائعة
- جمع أكثر من Bug بتكت واحدة — إلا إذا كانوا نفس الموضوع، وحينها افصلهم بأقسام واضحة داخل التكت.
- صور بلا سياق: لقطة للشاشة بلا الخطوة اللي وصلتك لها.
- كلام عام مثل «الأداء سيّئ» بدون رقم أو زمن قياس.
- مبالغة بالشدة لتسريع الإصلاح — بتضرّ مصداقيتك بعد مرّتين.
أسئلة شائعة
كم Bug لازم أفتح بالتكت الواحدة؟ موضوع واحد. إذا كانوا أخطاء مرتبطة بنفس الشاشة أو الميزة، اجمعهم بتكت واحدة بس افصل كل واحد بوصف ونتيجة فعلية ومتوقّعة خاصة فيه.
شو أعمل إذا الـ Bug ما بيتكرّر؟ افتح التقرير وبيّن إنّه متقطّع، مع نسبة التكرار، وأرفق فيديو ووقت الحدوث بالضبط.
مين بيحدّد الأولوية؟ غالباً الـ Product Owner أو مالك المنتج بناءً على أثر العمل، والمختبر بيحدّد الشدة ويقترح الأولوية.
التقرير لازم بالعربي ولا بالإنجليزي؟ حسب لغة فريقك؛ الأهم يكون بلغة واحدة ثابتة، والمصطلحات التقنية بالإنجليزي لتجنّب اللبس.
خطوتك الجاية
- حمّل قوالب QA الجاهزة واستخدم قالب تقرير الـ Bug مباشرة.
- إذا بتبني أساسك، ابدأ بدورة ISTQB CTFL V4.
- وأي مصطلح وقف معك، قاموس المصطلحات موجود.



النقاش 🔻