Race Condition: الكابوس الخفي الذي يهدد سلامة البيانات وتجربة المستخدم

حصلت معاك قبل كدة إنك تحجز آخر تيشيرت أونلاين، تدخل بيانات الكارت وتدفع، وفي الآخر يجيلك إيميل يقولك:
“آسفين، المنتج خلص!” 😤

هذا السيناريو الشهير يُعرف في عالم البرمجة والاختبار باسم:
🧨 Race Condition أو أحيانًا Stale Data.

📌 إيش هو الـ Race Condition؟
هو موقف بيحصل لما اتنين مستخدمين أو أكثر يحاولوا يعملوا تعديل أو إجراء على نفس البيانات (Record) في نفس اللحظة تقريبًا، والنظام ما عنده آلية تمنع التعارض أو تحدّث البيانات في الوقت الفعلي.
النتيجة؟ واحد منهم بيسبق ويحفظ، والتاني بيخسر أو بيكتب فوق تعديل غيره، والبيانات بتتلخبط أو تضيع.

📌 ليه الموضوع خطير؟
المشكلة دي مش بس بتقدم تجربة مستخدم سيئة، لكنها كمان خطر على سلامة البيانات (Data Integrity).

• في موقع تسوق: ممكن العميل يدفع لمنتج مش موجود في المخزون.
• في بنك: ممكن يتحوّل نفس المبلغ مرتين.
• في نظام مخزن أدوية: ممكن يتسجّل بيع دواء غير متوفر.

كل ده بسبب إن النظام مش متزامن ومفيش قفل (Lock) أو تحديث فوري عبر WebSocket أو آلية أخرى.

🛠 كيف نعمل Testing لسيناريو Race Condition؟

كـ QA Engineer لازم تكون مستعد تكتشف السيناريو ده قبل ما يوصل للعميل.
واحدة من الطرق الفعّالة هي Lost Update Test، وهي تجربة عملية لمحاكاة السباق بين مستخدمين.

خطوات المحاكاة:
1️⃣ افتح متصفحين مختلفين أو نافذتين Incognito علشان كل واحدة تمثل جلسة (Session) منفصلة.
2️⃣ سجّل دخول بحسابين مختلفين، مثل User A وUser B.
3️⃣ افتح نفس الصفحة أو نفس السجل (Record) في الحسابين، مثلاً صفحة منتج أو ملف موظف.
4️⃣ من عند User A: عدّل أي معلومة (زي السعر أو الكمية) لكن لا تحفظ التغيير بعد.
5️⃣ من عند User B: عدّل نفس المعلومة أو معلومة أخرى في نفس الـ Record.
6️⃣ اضغط Save أولاً من عند User A، وبعدها مباشرة (خلال ثانية) من عند User B.

💣 ماذا تراقب بعد الحفظ؟

• هل تعديل User A اختفى بعد ما حفظ User B؟
• هل التعديلات اندمجت بشكل غلط (Merge Issue)؟
• هل ظهر Error أو Conflict Message؟
• هل تم تحديث البيانات بشكل سليم بدون ضياع أي تعديل؟

لو لقيت أي مشكلة، فهذا Bug خطير، لأنه يعني إن النظام معرض لـ Data Loss أو Data Corruption.

🔍 ليه بتسمّى Lost Update؟

لأن التعديل الأول يضيع أو يتم الكتابة فوقه بسبب التعديل الثاني.
تخيل إنك بتكتب في ملف Word وزميلك بيكتب في نفس الملف من جهازه، وبيحفظ بعدك بثانية، فتضيع كل إضافتك!

💡 كيف يمنعها المبرمجون؟

• Optimistic Locking: التحقق من أن البيانات لم تتغير منذ آخر مرة قرأها المستخدم قبل الحفظ.
• Pessimistic Locking: حجز السجل ومنع أي تعديل عليه حتى يفرج عنه المستخدم الأول.
• Real-Time Sync باستخدام WebSocket أو إشعارات لحظية.
• عرض رسائل تحذيرية إذا حاول شخص حفظ على بيانات تم تعديلها من شخص آخر.

🧀 مثال بسيط للتوضيح

الموضوع بالضبط زي إنك واقف في طابور الكاشير ومعاك آخر علبة جبنة 🧀.
قبل ما توصل للكاشير، ييجي حد من آخر الطابور ويخطفها، والكاشير ما يلاحظش!
النتيجة: أنت دفعت ومفيش منتج!

🎯 دور الـ QA هنا

مهمتنا مش بس نختبر السيناريو العادي، لكن كمان نبحث عن الظروف الاستثنائية اللي ممكن تسبب مشاكل مستقبلية.
احنا كـ Testers لازم نكون “أمن السوبرماركت” اللي يمنع الفوضى ويحمي البيانات قبل ما تحصل الكارثة 💼🛡️