Frontend أم Backend؟ كيف تجمع أدلة المشكلة؟
تعلّم تتبّع المشكلة بين الواجهة والـAPI باستخدام Network وConsole، وجمع أدلة تساعد الفريق على تحديد السبب بدل التخمين.
المشكلة من الـFrontend أم الـBackend؟
تضغط على «حفظ»، تظهر رسالة نجاح، لكن البيانات لا تتغيّر. هل المشكلة من الواجهة أم من الخادم؟
المشهد وحده لا يكفي للحكم. قد ترسل الواجهة قيمة خاطئة، أو يفشل الخادم في حفظها، أو تُحفظ بنجاح لكن الشاشة تستمر بعرض البيانات القديمة.
دور الـQA هو تتبّع ما حدث وجمع أدلة تقلّل مساحة البحث، دون الحاجة إلى معرفة السطر البرمجي المسؤول عن كل مشكلة.
1. ثبّت خطوات إعادة المشكلة
قبل فتح أدوات المطوّر، حدّد:
- الخطوات الدقيقة والبيانات المستخدمة.
- النتيجة المتوقعة والنتيجة الفعلية.
- البيئة ورقم الإصدار والمتصفح.
- نوع الحساب وصلاحياته.
- هل تتكرر المشكلة دائمًا أم أحيانًا؟
مثال واضح: «بعد تعديل الاسم من أحمد إلى عمر والضغط على حفظ، تظهر رسالة نجاح، لكن الاسم يبقى أحمد حتى بعد تحديث الصفحة».
هذا الوصف أفضل من «تعديل الملف الشخصي لا يعمل».
2. راقب الطلب في Network
في Chrome، افتح DevTools ثم Network قبل إعادة تنفيذ الخطوات. استخدم فلتر Fetch/XHR للبدء بطلبات الـAPI، وارجع إلى All إذا لم تجد الطلب المتوقع.
حدّد الطلب المرتبط بالعملية، ثم افحص:
- URL وMethod: هل العملية تُرسل إلى العنوان الصحيح؟
- Payload: هل البيانات المرسلة تطابق ما أدخله المستخدم؟
- Status Code: ما كود الاستجابة؟
- Response: ماذا أعاد الخادم فعلًا؟
- Timing: أين يظهر التأخير في الطلب؟
إذا كانت العملية تنتقل إلى صفحة أخرى، فعّل Preserve log للاحتفاظ بالسجل أثناء التنقل.
لا تكتفِ بصورة للخطأ؛ اربط ما ظهر في الشاشة بالطلب الذي سبقه.
3. قارن المدخلات والطلب والاستجابة
لنفترض أنك غيّرت الاسم إلى «عمر». هذه أمثلة لما قد تجده:
| الدليل | اتجاه التحقيق |
|---|---|
| الشاشة تعرض «عمر»، لكن الطلب يرسل «أحمد» | افحص تجهيز البيانات وحالة النموذج في الواجهة |
| الطلب يرسل «عمر»، والاستجابة تعيد خطأ تحقق موثّقًا | قارن المدخلات بعقد الـAPI وطريقة عرض الخطأ |
| الحفظ يبدو ناجحًا، لكن طلب القراءة التالي يعيد الاسم القديم | افحص الحفظ ومصدر القراءة والتخزين المؤقت |
| طلب القراءة يعيد «عمر»، لكن الشاشة تعرض «أحمد» | افحص تحديث حالة الواجهة وربط البيانات بالعرض |
هذه مؤشرات وليست أحكامًا نهائية. تأكد من أنك تتابع الحساب والسجل والطلب الصحيح، ومن عدم وجود تأخير متوقع في تحديث البيانات.
4. افحص Console دون القفز للاستنتاج
قد يكشف Console خطأ JavaScript وقع عند الضغط على الزر أو معالجة الاستجابة.
سجّل نص الخطأ ووقت ظهوره، وتحقق من ارتباطه بخطوات المشكلة. وجود رسالة حمراء لا يعني تلقائيًا أنها السبب؛ فقد تكون من إضافة في المتصفح أو خدمة أخرى غير مرتبطة بالعملية.
كذلك، عدم ظهور طلب في Network لا يثبت وحده أن الزر معطّل. ربما منع التحقق المحلي الإرسال، أو أخفى الفلتر الطلب، أو بدأت التسجيل بعد حدوثه.
5. أعد تجربة الطلب عند الحاجة
يمكنك استخدام Postman لإعادة تجربة الطلب في بيئة اختبار، مع المحافظة على العناصر المؤثرة: العنوان، والطريقة، والبيانات، والحساب، والترويسات.
إذا تكرر الخلل خارج الواجهة، فهذا يساعد على تضييق التحقيق نحو الخدمة أو البيانات أو الإعدادات.
لكن نجاح الطلب في Postman لا يثبت أن المشكلة من كود الواجهة. المتصفح يطبّق قيودًا مثل CORS لا يطبّقها Postman بالطريقة نفسها، وقد تختلف ملفات الارتباط أو بيانات المصادقة بين التجربتين.
ولا تُعِد تشغيل طلبات الدفع أو الإنشاء عشوائيًا؛ استخدم بيانات اختبار واعرف الأثر المتوقع للعملية.
6. لا تحصر الاحتمالات في طرفين
قد يكون السبب من الشبكة، أو خدمة خارجية، أو بوابة API، أو إعدادات البيئة، أو Cache قديم.
كذلك، كود 500 لا يحدد المكوّن المسؤول بدقة، وكود 200 لا يثبت صحة نتيجة العمل. وحتى البطء قد يحدث في الطلب أو في معالجة البيانات وعرضها بعد وصولها.
اسأل دائمًا: أين ظهر أول اختلاف عن السلوك المتوقع؟
كيف تكتب تقريرًا يساعد المطوّر؟
استخدم عنوانًا يصف المشكلة، ثم أرفق الأدلة الأساسية:
العنوان: الاسم القديم يبقى ظاهرًا بعد نجاح التعديل.
المتوقع: ظهور الاسم الجديد بعد الحفظ.
الفعلي: استمرار عرض الاسم القديم.
الأدلة: طلب التعديل يرسل الاسم الجديد، وطلب القراءة التالي يعيده صحيحًا، بينما تعرض الشاشة القيمة السابقة.
اتجاه التحقيق المقترح: تحديث حالة الواجهة بعد الحفظ.
أضف الخطوات والبيئة والتوقيت وRequest ID إن توفر، لربط التجربة بسجلات الخادم. واحذف كلمات المرور والـTokens والبيانات الشخصية من المرفقات وملفات HAR قبل مشاركتها.
التقرير القوي لا يقول فقط «المشكلة من الـBackend»؛ بل يوضح ما أُرسل، وما عاد، وما ظهر للمستخدم.
النقاش 🔻