كتير مننا بيواجه Bugs ونقعد نسأل:
“مين هيحل دي؟ Backend ولا Frontend؟” 🤔
الموضوع مش بس Testing وخلاص. الـ QC الشاطر مش بيكتشف البج وبس، لكن كمان بيساعد في تحديد السبب بسرعة عشان يسرّع الـ Development Cycle، ويقلل وقت الـ Investigation.
في المقالة دي، هنتعلم خطوة بخطوة إزاي تفرّق البج Backend ولا Frontend باستخدام الـ Developer Tools في المتصفح.
الخطوة الأولى: افحص هل الـ Request وصل للـ Backend أصلاً
- افتح Inspect → Network Tab.
- كرر السيناريو اللي بيطلع البج.
- لو مفيش Request ظهر → المشكلة من Frontend.
- لو فيه Request ظهر → كمل للخطوة التانية.
الخطوة الثانية: افهم تفاصيل الـ Request
اضغط على السطر الخاص بالـ API وشوف:
1. Status Code
- 5xx أو رسالة خطأ جاية من السيرفر → Backend Bug صريح.
- 4xx (زي 400) ومعاها رسالة بتقول إن البيانات اللي بعتها غلط → غالباً Frontend (أنت اللي بعت فورم ببيانات غلط).
- 200 لكن القيم في الـ Response غلط (مثلاً السعر رجع 0 بدل 100) → راجع الـ Payload.
الخطوة الثالثة: افحص الـ Payload
الـ Request Payload بيورّيك البيانات اللي الـ Frontend بعتها للـ Backend.
- لو ناقص Field، أو الاسم غلط، أو الـ Format غلط → Frontend Bug.
🔹 مثال:
المفروض تبعت:
{ "email": "x@test.com", "age": 25 }
لكن لقيت:
{ "mail": "x@test.com" }
هنا طبيعي الـ Backend يرجع Error، لكن المشكلة أصلها Frontend.
الخطوة الرابعة: افحص الـ Response مع الـ UI
- Status 200 والداتا صح في الـ Response لكن الـ UI بيعرض أرقام غلط أو مبيعرضش حاجة → المشكلة Frontend (ممكن Format أو طريقة عرض).
الخطوة الخامسة: شوف الـ Console Tab
افتح Console Tab:
- لو لقيت JavaScript Errors → في الأغلب Frontend Bug.
أفضل ممارسات عند توثيق البج
- قبل ما تقول “Backend مش شغال” أو “Frontend بايظ”:
- صوّر الـ Network Tab وConsole Tab.
- حط الصور في التذكرة (Bug Ticket).
- ده بيقلل اللف والدوران، ويبين إنك فاهم وبتشتغل باحتراف.
الخلاصة
الـ QC Engineer مش “اللي بيعطل المراكب الماشية” 🚢، بل دوره إنه:
- يكتشف المشاكل بدري.
- يحدد سببها.
- يكتب Bugs واضحة بخطوات مفهومة.
- يقترح حلول وتحسينات.
بهذه الطريقة، بنسرّع الـ Development Cycle ونحسّن التعاون بين الفرق. 💪
test
mnnnnnnnnnnnnnnn
rrrrr
Test here
0