AIM Tech

🚨 لو الـManual Testing كانت البداية… فالـAutomation هي الخطوة الجاية!
كام مرة فكرت تبدأ Automation، وبعدها وقفت محتار:
❓ أبدأ منين؟
❓ أتعلم Selenium ولا Playwright؟
❓ هل لازم أكون قوي في البرمجة الأول؟
❓ وهل الـAutomation لسه تستاهل الوقت والمجهود؟
خلينا نقولها ببساطة:
أيوه… بس لازم تتعلمها صح. 🔥
وعشان كده 👇
🚀 Automation Testing – New Round is Coming!
راوند عملية هنبدأ فيها من الأساسيات، ونفهم الـAutomation مش كـTools بس، لكن كـ Mindset وطريقة تفكير.
والراوند المرة دي مختلفة… 👀
مش Tool واحدة.
مش مجرد كتابة Scripts.
ومش Automation بشكل تقليدي.
فيها أكتر من حاجة هتخليك تبني Automation Skillset متكامل. 💪
ولو بتفكر تبدأ Automation أو تطور مستواك فيها…
خليك متابع البوستات الجاية 👀🔥
لأننا هنكشف واحدة واحدة…
إيه اللي مستنيك في الراوند الجديدة؟ 🚀
للاستفسار كلمنا ع رسايل الصفحة أو من خلال https://wa.me/201552790104

كلنا كـ QAs بنسمع كتير عن الـ **Architecture** بتاعة السيستم اللي بنشتغل عليه...

لكن هل فكرت قبل كده قد إيه فهمك للـ **Software Architecture** ممكن يغيّر طريقة تفكيرك في الـ Testing من الأساس؟ 🤔

لأن الـ Architecture مش مجرد حاجة تخص الـ Developers.

هي اللي بتساعدك تفهم:

**إيه اللي ممكن يفشل؟
فين ممكن يفشل؟
وإزاي تختبره؟**

خلينا نشوفها في أكتر من Scenario 👇

🔹 **Monolithic Architecture**

السيستم كله موجود داخل Application واحدة وCodebase واحد.

ده ممكن يخلي الـ Integration Testing أبسط نسبيًا من ناحية الـ Setup، لأن الـ Components موجودة في نفس النظام.

لكن في المقابل، الـ Tight Coupling ممكن يخلي Change صغير في جزء من السيستم يأثر على أجزاء تانية.

وهنا الـ Regression Testing محتاج **Impact Analysis** كويس، مش مجرد إننا نعيد تشغيل نفس مجموعة الـ Test Cases كل مرة.

---

🔹 **Microservices Architecture**

هنا الـ System متقسم لخدمات مستقلة نسبيًا، وكل Service ممكن يكون ليها Database وAPI وDeployment الخاص بيها.

والـ Challenge هنا مش بس:

**"هل كل Service شغالة؟"**

لكن:

**"هل الـ Services دي بتتكلم مع بعض صح؟"**

هنا الـ Testing Strategy لازم تهتم بـ:

🔸 **Contract Testing**
هل الـ Consumer والـ Provider متفقين على نفس الـ Contract؟

🔸 **Integration Testing**
هل الـ Data Flow والـ Communication بين الـ Services شغالين صح؟

🔸 **Service Virtualization**
هل نقدر نختبر Service معينة من غير ما نكون معتمدين على كل الـ Dependencies تكون متاحة؟

وكمان لازم نفكر في سيناريوهات زي:

**Timeouts – Retries – Service Failures – Duplicate Requests – Data Consistency**

لأن الـ Bug ممكن مايبقاش في Service واحدة...

**ممكن يكون في الـ Communication بينها وبين Service تانية.**

---

🔹 **Event-Driven Architecture**

هنا الـ Services مش لازم تستنى Response مباشر من Service تانية.

Service تبعت **Event**...

Consumer يستلمه...

وبعدين يحصل Processing في وقت لاحق.

وده بيضيف نوع جديد من الـ Testing Challenges.

لازم نختبر:

✅ هل الـ Event اتبعت بالشكل الصحيح؟
✅ هل الـ Consumer استلمه؟
✅ هل اتعمل Processing صح؟
✅ ماذا يحدث لو الـ Event اتبعت مرتين؟
✅ ماذا يحدث لو الـ Consumer كان unavailable؟
✅ هل الـ Retry والـ Error Handling شغالين بالشكل المتوقع؟

والـ Asynchronous nature هنا بتخلي الـ Assertions نفسها محتاجة تفكير مختلف.

مش دايمًا تقدر تعمل:

**Action → Immediate Assertion**

ممكن تحتاج تتحقق من **Eventual Outcome** بعد سلسلة من الأحداث والـ Processing.

---

وده ليه فهم الـ Architecture مهم جدًا بالنسبة للـ **Senior QA / QA Lead**؟

لأنه بيساعدك تحدد:

🎯 الـ Testing Scope
🎯 الـ Real Risks
🎯 الـ Appropriate Testing Level
🎯 الـ Tools والـ Techniques المناسبة
🎯 وإزاي توزع الـ Testing effort بشكل فعّال

يعني بدل ما تسأل:

**"إيه الـ Test Cases اللي محتاج أكتبها؟"**

تبدأ تسأل:

**"إيه الـ Risks اللي الـ Architecture دي ممكن تعملها؟ وفين أفضل مكان أختبرها؟"**

وده في رأيي واحد من أهم الفروق بين:

**QA بيختبر الـ Features**

و

**QA بيفهم الـ System وبيصمم Testing Strategy حواليه.** 🎯

طيب، إيه أكتر Architectural Style غيّر طريقة تفكيرك في الـ Testing Strategy؟

**Monolith؟ Microservices؟ Event-Driven؟ ولا غيرهم؟** 👇

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

🎉 **خبر جديد من Success Stories بتاعتنا! ❤️**

مبروك لـ **ياسمين** على انضمامها لشركة **TakeTheme** وبدء خطوة جديدة في رحلتها المهنية! 👏🚀

من المذاكرة والتدريب والتطبيق… لحد ما وصلت لأول فرصة حقيقية في الـ Career.

والنجاح ده بالنسبة لنا مش مجرد **Job Offer**؛
هو كمان دليل مهم إن **مجال Software Testing لسه فيه فرص حقيقية**. 💙

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

لكن الصورة مش بالسوء اللي أحيانًا بتنتشر على السوشيال ميديا.
**الفرص موجودة… واللي بيجهز نفسه صح يقدر يوصل لها.** 🎯

كل طالب بيوصل لفرصة جديدة بيأكد لنا إن الرحلة تستاهل، وإن البداية الصعبة مش معناها إن الطريق مقفول. ✨

**مبروك يا ياسمين، فخورين بيكي وبالخطوة دي، وإن شاء الله تكون بداية لنجاحات أكبر وأكبر. 🤍**

Keep learning. Keep growing. Keep going. 🚀

لو بتفكر تبدأ في Software Testing، فممكن تكون دي اللحظة اللي مستنيها. 🚀

راوند جديدة للتحضير لامتحان **ISTQB Foundation Level** هتبدأ خلال أيام، والمرادي العدد **محدود** علشان نقدر نحافظ على المتابعة والتفاعل مع كل متدرب.

مش هدفنا إنك تحفظ الـ syllabus وتدخل الامتحان وخلاص…
هدفنا إنك **تفهم، تطبق، وتتدرب لحد ما طريقة تفكير الـ Tester تبقى طبيعية عندك.**

خلال الراوند هتشتغل على:
✅ شرح منهج ISTQB بشكل مبسط ومنظم
✅ حل وتدريب مستمر على أسئلة الامتحان
✅ متابعة وتقييم لمستواك
✅ أكثر من 100,000 امتحان وتدريب على الـ website
✅ امتحانات مخصصة حسب الجزء اللي ذاكرته
✅ ماتريال وأسئلة متنوعة للمراجعة
✅ دعم وتجهيز للخطوة اللي بعد ISTQB

ولو كل مرة بتقول:
*"هبدأ لما أكون جاهز..."*

فخليني أقولك:
**أنت مش محتاج تكون جاهز علشان تبدأ… أنت بتبدأ علشان تبقى جاهز. ❤️**

📌 الراوند هتبدأ خلال أيام
📌 الأماكن محدودة

لو حابب تعرف التفاصيل وتحجز مكانك، ابعتلنا رسالة 💬 سواء من خلال رسايل الصفحة أو من خلال https://wa.me/201552790104 وهنساعدك بكل التفاصيل .. مستنينك

أكتر حاجة ممكن تفرق في الـ **Quality** بتاعة أي SaaS Product مش عدد الـ Test Cases اللي عندك...

لكن **قد إيه الـ QA Team فاهم الـ Architecture اللي الـ Product مبني عليها.** 🤔

لأن الـ Testing مش مجرد:

*"أختبر الـ UI وأجرب الـ APIs."*

كل ما فهمت الـ Structure اللي ورا الـ Product، كل ما قدرت تعرف:

**إيه اللي ممكن يفشل؟ وفين؟ وليه؟**

خلينا ناخد مثال واضح 👇

🔹 **Monolithic Architecture**

عندك Codebase واحد، والـ Components والـ Business Logic موجودين جوه Application واحدة، وغالبًا الـ Deployment بيكون كوحدة واحدة.

وده بيخلي بعض الـ Integration Scenarios أبسط من الأنظمة الموزعة.

لكن في المقابل، الـ Tight Coupling ممكن يخلي Change صغير في Module واحدة يأثر على أجزاء تانية من الـ System.

وهنا الـ Regression ممكن يتحول لكابوس لو مفيش **Impact Analysis** وTest Coverage مبنيين على الـ Risks. 😱

---

🔹 **Microservices Architecture**

هنا الـ System متقسم لـ Services مستقلة نسبيًا، وكل Service ممكن يكون ليها Database وAPI والـ Deployment الخاص بيها.

وده بيغير الـ Testing Strategy تمامًا.

لأن ممكن تلاقي:

**Service A ✅**
**Service B ✅**

لكن لما الاتنين يتكلموا مع بعض...

**💥 Something breaks.**

وهنا بيظهر دور الـ QA الحقيقي.

🔸 **Service-level Testing**

اختبر كل Service بشكل مستقل، وركز على الـ Business Logic والـ API Contracts الخاصة بيها.

🔸 **Contract Testing**

مش كفاية إن الـ API ترجع Response صح.

لازم تتأكد إن الـ Consumer والـ Provider متفقين على نفس الـ Contract:

**Request → Response → Schema → Behavior**

🔸 **Integration Testing**

هنا تختبر الـ Communication بين الـ Services:

هل الـ Data بتتنقل صح؟

هل الـ Error Handling شغال؟

ماذا يحدث لو Service B Down؟

ماذا يحدث لو الـ Response اتأخر؟

وماذا يحدث لو نفس الـ Request اتكرر؟

🔸 **End-to-End Testing**

لسه مهم جدًا، لكن مش المفروض نعتمد عليه عشان يغطي كل حاجة.

الهدف هنا إننا نختبر **Critical User Journeys** عبر أكتر من Service ونتأكد إن الـ System كله بيحقق الـ Business Flow المطلوب.

---

وده اللي بيخلي فهمك للـ Architecture مهم جدًا كـ QA.

لأنك مش هتبقى بتكتب Test Cases للـ APIs بشكل منفصل...

هتبدأ تشوف الـ **Data Flow** بين الـ Services، وتفكر في:

**Dependency Failures**
**Timeouts**
**Retries**
**Duplicate Requests**
**Partial Failures**
**Data Consistency**
**Contract Changes**

والأهم...

هتعرف **فين تختبر كل Risk** بدل ما تحاول تغطي كل حاجة بـ E2E Tests.

وده فرق كبير بين إنك تكون:

**QA بيختبر الـ Features**

وبين:

**QA بيفهم الـ System وبيصمم Testing Strategy حوالي الـ Risks.** 🎯

لأن الـ Quality مش بتتحسن لمجرد إن عندك Tests أكتر...

**بتتحسن لما تكون عارف تختبر إيه، وفين، وليه.**

لو اشتغلت على SaaS مبني على Microservices، إيه أكتر Integration Challenge قابلته؟

**Contract؟ Data Consistency؟ Service Dependency؟ ولا Failure Handling؟** 👇

كـ **QA Lead أو Test Manager**، واحدة من أكتر الحاجات اللي بتفرق فعلًا في الـ Testing Strategy بتاعتك مش بس:

**"How to Test?"**

لكن الأهم:

**"What to Test?" و "Where exactly should I test it?"** 🤔

والإجابة على السؤالين دول غالبًا بتبدأ من حاجة أساسية جدًا:

**Software Architecture.**

لأن الـ Architecture مش مجرد حاجة تخص الـ Developers...

هي كمان **البوصلة اللي بتحدد إيه الـ Risks اللي تدور عليها، وفين ممكن الـ Failures تحصل، وعلى أي Level تختبرها.**

خلينا نشوف الفرق 👇

🔹 **Monolithic Architecture**

لما أغلب الـ Business Logic والـ Components موجودة داخل Application واحدة، الـ Internal Integration بيكون غالبًا أبسط من الأنظمة الموزعة.

لكن في المقابل، الـ Tight Coupling والـ Large Scope ممكن يخلوا أي Change صغير يأثر على أجزاء كتير من السيستم.

هنا كـ Lead، محتاج تهتم بـ:

• Critical End-to-End Flows
• Regression Impact
• Business Rules & Integration Points
• Overall System Stability
• Performance تحت الأحمال المختلفة

والأهم إنك ما تقعش في فخ إنك تختبر كل حاجة E2E لمجرد إن السيستم Monolith.

وزّع الـ Testing على الـ right level بدل ما تخلي الـ E2E يغطي كل حاجة.

---

🔹 **Microservices Architecture**

هنا الـ Story مختلفة تمامًا.

عندك Services مستقلة، كل Service ممكن يكون ليها Database أو Storage خاص بيها، والتواصل بينهم بيحصل من خلال APIs أو Events.

وده بيخلق نوع جديد من الـ Risks:

Service A شغالة تمام لوحدها...

Service B شغالة تمام لوحدها...

لكن **A + B مع بعض؟** 😬

هنا لازم الـ Strategy تشمل:

**Contract Testing**
عشان تتأكد إن الـ Consumers والـ Providers متفقين على الـ API Contract.

**Service-level Testing**
اختبار كل Service بشكل معزول، عشان تكتشف المشكلة في مكانها بدل ما تستنى E2E يفشل.

**Integration Testing**
للتأكد إن الـ Services بتتفاعل مع بعض بشكل صحيح.

**Distributed Tracing & Logging**
لأن لما الـ Request يعدي على 5 Services وتلاقي الـ User واخد Error...

السؤال مش بس:
*"هل فيه Bug؟"*

لكن:
**"فين بالضبط حصل الـ Failure؟"**

---

🔹 **Event-Driven Architecture**

هنا الموضوع بيزيد تحديًا لأن الـ Flow مش دايمًا Synchronous.

Service تبعت Event...

Service تانية تستقبله...

وبعدين Handler يعمل Action...

وممكن الـ User أصلًا يكون مش شايف أي حاجة من اللي حصل في الخلفية.

عشان كده لازم تفكر في:

• Event Flow Testing
• Asynchronous Behavior
• Duplicate Events
• Event Ordering
• Retry & Failure Handling
• Dead-letter Scenarios
• Observability

لأن أحيانًا الـ Bug مش في الـ Service نفسها...

**الـ Bug في اللي حصل بين Services.**

---

🔹 **Serverless Architecture**

هنا كمان الـ Testing Strategy بتتغير.

بدل ما تختبر Application واحدة كبيرة، ممكن يكون عندك Functions صغيرة بتشتغل بناءً على Triggers مختلفة.

فلازم تسأل:

هل الـ Trigger اشتغل؟

هل الـ Function اتنفذت؟

ماذا يحدث لو الـ Function فشلت؟

هل الـ Retry Behavior صحيح؟

وماذا يحدث لو نفس الـ Event اتبعت أكثر من مرة؟

وهنا الـ **Monitoring & Observability** مش رفاهية...

دي جزء أساسي من قدرتك على اختبار وفهم النظام.

---

وعشان كده، فهمك للـ Architecture كـ Lead مش مجرد Knowledge إضافية.

هو اللي بيساعدك تحدد:

**1️⃣ أين توجد الـ Risks؟**

**2️⃣ على أي Testing Level تختبرها؟**

**3️⃣ ما نوع الـ Test المناسب لكل Risk؟**

**4️⃣ ما الأدوات والـ Automation المناسبة؟**

**5️⃣ وكيف توجّه فريقك بدل ما توزع عليهم Test Cases بشكل عشوائي؟**

لأن الـ Testing Strategy القوية مش معناها إن عندك عدد أكبر من الـ Test Cases.

**معناها إنك عارف تختبر إيه، وفين، وليه.** 🎯

وده واحد من أهم الفروق بين:

**QA بيختبر الـ Features**

و

** Lead بيفهم الـ System وبيصمم Strategy حوالين الـ Risks.**

طيب، لو اشتغلت قبل كده على **Monolith / Microservices / Event-Driven / Serverless**...

إيه الـ Architecture اللي غيرت طريقة تفكيرك في الـ Testing أكتر؟

وإيه الـ Risk اللي اكتشفته بسبب فهمك للـ Architecture؟ 👇

كتير بنسمع عن **Usability Testing**، وغالبًا بنفكر إنه مجرد إننا نشوف الـ User بيتعامل مع الـ UI بسهولة ولا لأ.

لكن فيه سؤال أهم:

هل فهمك للـ Frontend ممكن يخليك تكتشف مشاكل Usability أعمق من اللي الـ User نفسه يقدر يوصفها؟🤔

لأن الـتيستر القوي مش بيكتفي إنه يقول:

❌ "الزرار مش واضح."

لكن بيبدأ يسأل:

ليه مش واضح؟ وإيه اللي حاصل تحته؟

خلينا ناخد كام مثال 👇

🔹 DOM & HTML Structure

لو الـ User مش قادر يوصل لعنصر أو بيتعامل مع الـ UI بشكل confusing، فهمك للـ DOM ممكن يساعدك تكتشف إن المشكلة مش مجرد شكل.

ممكن تكون في الـ HTML structure نفسه، ترتيب العناصر، أو الـ Semantic Elements المستخدمة.

وده كمان بيدخلنا في نقطة مهمة جدًا: Accessibility.

لأن الـ UI ممكن يكون شكله ممتاز بالنسبة للمستخدم العادي، لكن استخدامه يكون صعب جدًا لمستخدم بيعتمد على Keyboard Navigation أو Screen Reader.

فهمك للـ HTML والـ Accessibility يخليك تختبر حاجات زي:

هل الـ Buttons فعلًا Buttons؟
هل الـ Form Fields مرتبطة بالـ Labels؟
هل العناصر قابلة للوصول بالـ Keyboard؟
هل الـ Focus واضح؟
وهل الـ Screen Reader يقدر يفهم الـ Content بشكل منطقي؟

وهنا بتكتشف إن **Usability مش معناها إن الـ UI شكله حلو وبس.

🔹 CSS & Responsive Behavior

زرار واضح جدًا على Desktop، لكن على Mobile بقى صغير، اتزاحم مع عنصر تاني، أو اختفى جزء منه.

هنا فهمك للـ CSS والـ Responsive Design يخليك تفكر في سيناريوهات أبعد من مجرد:

"الـ UI شكله غلط."

وتبدأ تختبر:

Different screen sizes → Different layouts → Different User Experience.

🔹 JavaScript & Dynamic Rendering

أحيانًا الـ User يعمل Action، لكن الـ UI يتأخر في التحديث أو جزء من الصفحة يتغير بشكل مفاجئ.

هنا فهمك للـ Rendering والـ JavaScript يخليك تسأل:

هل الـ UI اتحدث فعلًا بعد الـ Action؟
هل فيه Loading State؟
هل الـ Old Data لسه ظاهرة؟
هل حصل Race Condition؟

ودي كلها حاجات ممكن تتحول من مجرد "UI Issue" لـ Real Usability Problem.

🔹 State Management

تخيل User يغير Filter أو يعمل Update لبيانات، وبعد Navigation أو Refresh يلاقي الـ UI رجع لحالة قديمة.

فهمك للـ State Management يخليك تفكر:

هل المشكلة فيComponent State؟
ولا Global State؟
ولا الـ State مش متزامن مع الـ Backend؟

وهنا بتبدأ تربط بين:

Technical Behavior → User Experience.

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

وتيستر بيفهم المشكلة.

لأن لما تكون فاهم الـ Frontend، الـ Bug Report بتاعك مش هيكون:

❌ "The page is confusing."

لكن ممكن يكون:

✅ إيه الـ User Action اللي أدى للمشكلة
✅ إيه الـ Expected والـ Actual Behavior
✅ هل المشكلة مرتبطة بـ Responsive Behavior أو Accessibility أو State أو Rendering
✅ إيه الـ Scenarios اللي ممكن تتكرر فيها المشكلة
✅ وإيه الـ Technical Area اللي محتاج يتراجع

وده مش معناه إن دور الـتيستر يتحول لـ Developer.

لكن كل ما فهمت الـ System اللي بتختبره، كل ما قدرت تسأل أسئلة أذكى وتكتشف Bugs كان ممكن تعدي بسهولة.

فهم الـ Frontend بيحولك من مجرد Observer للـ UI... إلى Problem Solver بيفهم ليه المشكلة حصلت وتأثيرها على الـ User.🕵️‍♀️

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