AIM Tech

**"البج مش في الـ Feature الجديدة... لكن في ترتيب الخطوات!"**

من أكثر أنواع المشاكل التي يتم تجاهلها أو حتي نسيانها أثناء الاختبار:

**State Transition Bugs**

أغلبنا يختبر هل النظام ينفذ العملية أم لا ((شغال ولا لاء))

لكن السؤال الأهم أحيانًا:

**هل يسمح بتنفيذها في الوقت الصحيح فقط؟**

تخيل نظام طلبات يمر بالمراحل التالية:

Draft → Pending → Approved → Completed

طبيعي أن الطلب ينتقل من مرحلة لأخرى بالترتيب.

لكن ماذا لو استطاع المستخدم:

❌ الانتقال من Draft مباشرة إلى Completed؟

❌ تعديل الطلب بعد اعتماده؟

❌ إلغاء طلب مكتمل بالفعل؟

❌ إعادة الطلب إلى حالة غير منطقية؟

هنا المشكلة ليست في الوظيفة نفسها...

بل في السماح بانتقالات (Transitions) غير صحيحة بين الحالات.

عند اختبار أي Workflow اسأل نفسك دائمًا:

🔹 ما الحالات المسموح الانتقال بينها؟
🔹 ما الحالات الممنوع الانتقال بينها؟
🔹 هل الصلاحيات تختلف حسب الحالة؟
🔹 ماذا يحدث إذا حاول المستخدم تنفيذ Action في حالة غير متوقعة؟
🔹 هل الـ API تمنع الانتقال غير الصحيح أم أن المنع موجود فقط في الـ UI؟

كثير من الأنظمة تبدو مستقرة عند اختبار Happy Path...

لكنها تنهار عندما يجرب شخص الانتقال بين الحالات بطريقة لم يفكر فيها أحد.

ولهذا السبب، من أقوى الـ Test Cases التي يمكن أن تكتبها ليست:

"هل يعمل الزر؟"

بل:

(((هل يعمل الزر فقط عندما يجب أن يعمل؟)))

لو فادك موضوع النهارده استنى البوست الجاي هنكمل شرح دور ال API تيستنج وازاي بيكون خط الحماية الاخير وعلاقه ال business logic
ولحد البوست الجديد زور موقعنا واستفيد بكل المحتوي الموجود لافادتك ومساعدتك تغير من طريقة تفكيرك https://aimtech.online/posts

Caching Bugs vs Real Data: لما السيستم يقولك “أنا صح” وهو مش شايف الحقيقة

أحيانًا السيستم بيرد عليك بثقة كاملة…
لكن هو بيرد من الكاش.
مش من الداتا الحقيقية.

والفرق ده ممكن يعمل Production Incident محترم 👀

🧠 المشكلة فين؟

الكاش معمول عشان:

يسرّع القراءة
يقلل الضغط على الداتا بيز
يحسّن الأداء

بس لو الكاش ما اتحدثتش في الوقت الصح…
هتبدأ تشوف “نسخة قديمة من الحقيقة”.

🎯 مثال عملي:

يوزر عدّل اسمه.
الـ Update نجح.

لكن لما دخل بروفايله…
الاسم القديم لسه ظاهر.

ليه؟

لأن:

الداتا اتحدثت
لكن الـ Cache لسه محتفظة بالقيمة القديمة
أو الـ TTL لسه ما خلصش

السيستم مش غلطان.
هو بس شايف صورة قديمة.

🎯 مثال أخطر:

Admin عطّل حساب مستخدم.

المفروض ميقدرش يعمل Login.

لكن لو:

الـ Session متخزنة في Cache
أو Status الحساب متخزن

المستخدم ممكن يفضل يدخل عادي
لحد ما الكاش تتحدث.

ده مش UI Bug.
ده Cache Invalidation Issue.

🧨 المشكلة الأكبر؟

لما التستر يختبر بسرعة:

يعمل Update
يعمل Refresh فورًا
يشوف القيمة القديمة
يفتح Bug

أحيانًا ده مش Bug…
ده سلوك كاش طبيعي.

لكن أحيانًا
يبقى Invalidation Logic ناقص.

والفرق بينهم لازم يتفهم.

🧠 كـ Tester لازم تسأل:
هل في Cache Layer؟ (Redis؟ CDN؟ Browser Cache؟)
الـ TTL قد إيه؟
هل في Cache Invalidation بعد الـ Update؟
هل القراءة جاية من نفس المصدر؟
هل في اختلاف بين Web و Mobile بسبب الكاش؟
🎯 تمرين عملي:

اعمل Update.
استني دقيقة.
اعمل Refresh.

لو النتيجة اتغيرت بعد وقت…
يبقى عندك Caching Behavior.

لو مفيش تغيير خالص…
ممكن يكون عندك Bug حقيقي.

القاعدة الذهبية:

الـ Cache مش مجرد تحسين أداء…
دي نسخة مؤقتة من الحقيقة.

ولو ما فهمتش النسخة دي بتتحدث إزاي
ممكن تفتح Bug غلط…
أو تفوت Bug أخطر 👀🔥

ولأن الموضوع ده مهم استنوا بوست تاني هنتكلم فيه بشكل أكبر واعمق بس استنى ممكن خلال الوقت ده تزور موقعناhttps://aimtech.online/posts هتلاقي فيه معلومات أكتر وأفيد تساعدك تكون تستر فاهم الكونسبت مش مجرد بتست اللي قدامك 💪