AIM Tech

"هل فعلاً كل Requirement لازم يتكتب لها Test Case؟" 🤔

في بداية أي مشروع، أول رد فعل عند كثير من الـ Testers:

"يلا نكتب Test Cases لكل حاجة."

لكن مع الوقت تكتشف أن الموضوع مش بالبساطة دي

تخيل أن عندك Feature فيها:

10 حقول إدخال.
5 أنواع مستخدمين.
عشرات الاحتمالات المختلفة للبيانات.

لو حاولت تكتب Test Case لكل سيناريو ممكن...

قد تنتهي بمئات أو آلاف الـ Test Cases.

وفي النهاية؟

❌ وقت صيانة Maintenance ضخم

❌ تكرار كثير.

❌ صعوبة في مراجعتها وتحديثها.

الـ Tester القوي لا يفكر في عدد الـ Test Cases.

بل يفكر في قيمة الـ Test Cases

يسأل نفسه:

✅ ما السيناريوهات الأكثر خطورة على البزنس؟

✅ ما الأجزاء الأكثر عرضة للفشل؟

✅ ما الذي قد يسبب خسارة للمستخدم أو للشركة؟

✅ أين يجب أن أركز جهدي ووقتي؟

لهذا السبب ظهر مفهوم مهم جدًا هو:

Risk-Based Testing

بدل أن تعامل كل Requirement بنفس الأهمية...

تعطي الأولوية لما يحمل أكبر تأثير وأكبر احتمال للفشل.

في النهاية...

الهدف ليس أن تمتلك أكبر عدد من الـ Test Cases.

الهدف أن تمتلك Test Cases قادرة على اكتشاف المشاكل التي تهم فعلًا.

وده يودينا ل نقطة مهمة جدًا بيقع فيها كثير من الـ Testers:

التعامل مع كل Bugs وكأنها بنفس الخطورة.

تخيل السيناريوين دول:

🔹 زرار في صفحة الإعدادات غير محاذي بشكل صحيح.

🔹 المستخدم يستطيع إتمام عملية شراء بدون خصم الرصيد أو الدفع الفعلي.

الاتنين Bugs.

لكن هل الاتنين بنفس الأهمية؟

طبعًا لا.

الـ Tester القوي لا ينظر فقط إلى وجود المشكلة...

بل ينظر إلى تأثيرها على البزنس والمستخدم.

يسأل نفسه:

✅ هل المشكلة تمنع المستخدم من إكمال هدفه؟

✅ هل تؤثر على الإيرادات؟

✅ هل تسبب فقدان بيانات؟

✅ هل لها تأثير أمني؟

✅ كم عدد المستخدمين المتأثرين بها؟

أحيانًا Bug بسيط في الشكل لا يستحق تأخير الـ Release.

وفي المقابل...

Bug صغير جدًا في منطق العمل (Business Logic) قد يكلف الشركة آلاف أو ملايين.

لذلك أثناء الاختبار لا تركز فقط على اكتشاف المشاكل...

ركز أيضًا على فهم خطورتها وتأثيرها الحقيقي.

لأن قيمة الـ Tester لا تُقاس بعدد الـ Bugs التي يكتشفها فقط...

بل بقدرته على مساعدة الفريق في التركيز على ما يستحق الاهتمام أولًا.

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

Cache Invalidation: Why It’s One of the Hardest Problems in Software

في مقولة مشهورة جدًا وسط الـ Engineers بتقول:

“There are only two hard things in Computer Science: Cache Invalidation and naming things.”

ولسبب حقيقي جدًا

المشكلة مش إنك تعمل Cache

المشكلة:
إمتى تعرف إن الكاش بقت غلط؟

لأن أول ما الداتا الأصلية تتغير…
أي نسخة متخزنة منها تبدأ تتحول لخطر محتمل.

مثال عملي بسيط:

Product سعره = 1000
السعر متخزن في Cache لتسريع القراءة.

Admin غيّر السعر لـ 800.

لو الكاش ما اتمسحتش أو اتحدثتش فورًا
بعض المستخدمين هيشوفوا:

1000
وبعضهم 800

والأسوأ؟
ممكن يدفع بسعر
ويتحاسب بسعر تاني.

المشكلة بتكبر جدًا في الأنظمة الكبيرة

لأن الكاش مش Layer واحدة بس.

ممكن يكون عندك:

Browser Cache
CDN Cache
API Gateway Cache
Redis Cache
Mobile Local Cache

والسؤال المرعب:

مين فيهم محتاج يتحدث؟
وإمتى؟
وبأي ترتيب؟

سيناريو Production حقيقي جدًا:

User غيّر صورة البروفايل.

الداتا اتحدثت
الـ API بترجع الصورة الجديدة
لكن الـ CDN لسه كاش الصورة القديمة
والموبايل كمان عامل Local Cache

النتيجة؟

الويب شايف صورة
الموبايل شايف صورة
User تاني شايف صورة ثالثة 😅
ليه الموضوع صعب فعلًا؟

لأن عندك معادلة مستحيلة شوية:

كل ما الكاش تعيش أطول:
✔️ Performance أحسن
❌ البيانات أقدم

كل ما تحدث الكاش بسرعة:
✔️ البيانات أحدث
❌ ضغط أكبر على السيستم

فأنت طول الوقت بتوازن بين:
Performance vs Consistency

كـ Tester التفكير هنا مختلف

أنت مش بس بتسأل:
“هل الداتا اتغيرت؟”

أنت لازم تسأل:

مين لسه شايف النسخة القديمة؟
بعد قد إيه المفروض الكل يشوف التحديث؟
هل في Forced Refresh؟
هل الـ CDN عندها Purge؟
هل الـ Mobile Cache بتتمسح بعد الـ Update؟
🎯 نقطة ناس كتير بتنساها:

بعض Bugs الكاش
“بتختفي لوحدها”

وده أخطر نوع Bugs 👀

لأن:

التستر يفتح Bug
بعد 5 دقائق كل حاجة تبقى صح
الفريق يقفل البج “Cannot Reproduce”

بينما المشكلة الحقيقية:
كانت Delay في Invalidation.

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

الـ Cache مش Source of Truth.
هي مجرد Snapshot مؤقتة.

ولو السيستم نسي إمتى يمسح الـ Snapshot دي…
المستخدم هيعيش في نسخة قديمة من الواقع

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