Slack Agentic Testing - Where Agents Fit in the E2E Testing

المقدمة

فريق الـ Engineering في Slack، بدأ يجرب حاجة اسمها Agentic Testing — بمعنى تاني تسيب الـ AI agent يعمل الـ testing بدل ما تكتبه بإيدك. والسؤال المهم هنا: هل ده هيحل محل الـ tests التقليدية؟ ولا مكانه مختلف خالص؟ وايه المميزات اللي بيقدمها؟

مصطلحات مهمة — Terminologies

قبل ما ندخل في التجربة علطول، خلونا نتكلم عن بعض المصطلحات عشان الكلام كله يكون واضح:

• الـ E2E Testing (End-to-End): ده اختبار بيتأكد إن التطبيق شغال من أوله لآخره زي ما المستخدم الحقيقي هيستخدمه، يعني بدل ما تختبر function صغيرة لوحدها، إنت بتمثّل رحلة كاملة: افتح الصفحة → اضغط زرار → اكتب حاجة → اتأكد إن النتيجة ظهرت صحيحة.
• الـ Deterministic Test: هو عبارة عن test "محدد سلفًا" — بيعمل نفس الخطوات بالظبط في كل مرة، ولو الظروف اتغيرت بيفشل .. بمعنى تاني هو بيكون test متوقّع ومكرر.
• الـ Playwright: من أشهر الـ frameworks لكتابة الـ E2E tests للمواقع ، وبيتحكم في المتصفح بالكود (يفتح صفحات، يضغط، يكتب... إلخ).
• الـ MCP (Model Context Protocol): بروتوكول بيسمح للـ agent إنه يتكلم مع أدوات خارجية بطريقة منظّمة (structured)، فهنا Playwright MCP بيدّي الـ agent أوامر جاهزة للمتصفح.

الانتقال من اختبار "الرحلة" لـ "الهدف" — الفرق الجوهري

الفكرة كلها بتبدأ من هنا: الـ test التقليدي بيختبر رحلة محددة جوه الـ UI:

click → click → type → assert

يعني إنت بتقوله بالظبط: دوس هنا، بعدين هنا، اكتب كده، وبعدين اتأكد إن كذا حصل .. ولو أي حاجة اتحركت من مكانها، الـ test طبعًا بيقع.

بينما الـ agent بيشتغل بطريقة تانية ومختلفة خالص: إنت بتديله هدف (goal)، وهو اللي بيدبّر نفسه:

goal → agent adapts → verify result

فمثلًا بنقوله: "ابعت رسالة في thread" — وهو بقى يشوف إزاي يعملها .. الجملة اللي ممكن تلخّص الفكرة كلها هي إن:

الـ Tests بتفرض رحلة محددة بينما الـ Agents بتتحقق من الهدف (Tests enforce journeys. Agents verify goals.)

الـ Diagram ده بيوضّح الفرق:

في تجارب Slack، الـ workflow العام فضل ثابت (مثلًا: login → search → result → clear)، لكن الخطوات بالتفصيل اتغيرت من run للتاني، فالـ agent كان بياخد طرق مختلفة يوصل بيها لنفس النتيجة:

• طرق إدخال مختلفة (يدوس على اقتراح في الـ search vs يدوس Enter)
• أنماط navigation مختلفة (يفتح الـ search من جديد vs يستخدم الـ state الموجود)
• خطوات زيادة أو ناقصة (ضغطات زيادة، snapshots، أو خطوات وسيطة)

المشكلة الحقيقية

الـ agentic testing شكله حلو وجميل، بس فيه سؤال محرج شوية لازم نسأله:

حاجة بتكلّف من 15 لـ 30 دولار في الـ run الواحد وبتاخد أكتر من 10 دقايق — هل ممكن تدخل فعلًا في workflow حقيقي؟

من أول نظرة الإجابة تبان إن بكل تأكيد "لأ"... بس بعد أكتر من 200 run، هنلاقي Slack اكتشفت إنها حاجة مختلفة جوهريًا عن الـ tests التقليدية، وممكن تبقى reliable جدًا، وليها مكان واضح في الـ testing stack.

السبب في كل ده هو التطور اللي حصل في الـ LLMs مؤخرًا، واللي خلّى الـ agents تقدر تكتب كود، وتعمل debug للـ failures، وتتفاعل مع الـ UI مباشرة بسهولة وسلاسة.

التجربة نفسها

عشان يفهموا الـ agent-driven tests ازاي تقدر تـ Fit وتكون جزء أساسي وضمن هيكلة الـ Testing Stack، فـ Slack شغّلت أكتر من 200 execution عن طريق إعدادات مختلفة، وكانوا هدفهم إنهم يقيسوا من خلالها 3 حاجات: الـ reliability، السرعة، والتكلفة.

نماذج التنفيذ — Execution Models

جرّبوا ٣ طرق مختلفة:

1. الـ Agent + Playwright MCP: الـ agent بيتعامل مع المتصفح من خلال الـ Playwright MCP، بيستخدم أوامر جاهزة (دوس على element، اكتب input، اقرا الـ DOM state...) مع الاحتفاظ بالـ context (snapshots و logs).
2. الـ Generated Playwright Tests: هنا الـ agent بياخد وصف بلغة عادية جدًا، ويكتب كود Playwright حقيقي (deterministic)، يشغّله كـ E2E test عادي، ويظبطه شوية بشوية لحد ما ينجح.
3. الـ Agent + Playwright CLI: الـ agent بيشغّل أوامر Playwright من الـ shell، وبينفّذ خطوة واحدة كل مرة، ويقرر اللي بعدها بناءً على حالة الـ UI الجديدة.

إعدادات التجربة — Setup

• الـ Model للـ MCP/CLI كان: Claude Sonnet 4.5
• الـ Model للـ Generated Tests كان : Claude Opus 4.6
• التنفيذ: Claude Code بوضع non-interactive (claude -p)
• كل التجارب اتعملت في test workspaces ببيانات مش حقيقية (non-production data) — ودي نقطة مهمة جدًا للأمان.

الـ Flows اللي اتجربت

استخدموا 2 flows بس بمستويات تعقيد مختلفة، وثبّتوهم في كل التجارب عشان المقارنة تبقى عادلة:

• الـ Thread Reply (بسيط): ~15–20 خطوة — يعمل channel، يبعت رسالة، يرد في thread، ويتأكد من حالة الـ thread.
• الـ Search Discovery (متوسط): ~25–30 خطوة — يكتب search queries، يتنقّل في النتايج، يتحرك بين الـ views المختلفة (search, channels, threads)، ويتأكد من النتايج.

شكل الـ Input

للطرق اللي فيها agent، جرّبوا نوعين من الـ Inputs:

• الـ Natural Language (NL): تعليمات مكتوبة بلغة بشرية عادية بالتفصيل (مثلًا: "رد في thread، واتأكد إنه ظهر في All Threads").
• الـ Structured YAML: نفس الـ workflow بس بصيغة منظّمة، بخطوات و actions و targets و expected outcomes واضحة.

والفرق هنا مكنش في كمية التفاصيل، ولكن الفرق في إزاي التفاصيل متمثّلة: الـ NL بيحتاج الـ agent يفسّر ويترجم الكلام لأفعال، أما الـ YAML فبيحدد الربط ده بشكل صريح أكتر وبشكل مباشر.

Experiment Matrix

كل Configuration اشتغل تقريبًا 20 مرة:

النتايج — اللي لاحظوها

خلونا نفصّص النقاط دي واحدة واحدة.

1) الاعتمادية — Reliability

أكتر pattern واضح شافوه: هو إن الـ reliability بتتغير كل ما الـ flow يبقى أعقد.

• الـ Playwright MCP كان الأكثر ثباتًا — failure قريب من الصفر في السيناريوهات البسيطة، وبين 0–12% في الأعقد.
• الـ Playwright CLI كان failure أعلى (تقريبًا 12–20%)، ومعظم المشاكل كانت من حاجات تنفيذية زي الـ authentication، توقيت الـ navigation، وعدم استقرار الـ session — مش من تفكير الـ model نفسه.
• الـ Generated Tests كانت كويسة في البسيط (~8%)، بس اتدهورت بشكل كبير في الأعقد (~48%). الحلو إنها مكانتش غلط تمامًا — كانت بتكمّل 70–80% من الـ flow وبعدين تقع في آخر تفاعل أو assertion.

ليه الفرق ده؟ السبب الأرجح هو إزاي كل طريقة بتتعامل مع الـ state:

• الـ MCP بيحتفظ بـ نظرة حية ومستقرة للتطبيق.
• الـ CLI بيعيد بناء الـ state من snapshots في كل خطوة — فالأخطاء الصغيرة بتتراكم كل ما الـ flow يطول.

وفي عامل تاني: in-session context. في الـ MCP، الـ agent بيبان إنه بيعيد استخدام تفاعلات ناجحة من خطوات سابقة في نفس الـ flow، بينما الـ CLI بيحسّ إنه بيبدأ من الأول كل خطوة.

2) السرعة — Speed

نقطة مهمة: وقت الـ Generated Tests شامل الـ generation + التنفيذ. التنفيذ الخام لوحده كان أسرع بكتير: ~32 ثانية للـ thread reply و~45 ثانية للـ search. في بيئات الـ CI اللي بتشغّل الـ tests مرات كتير، تكلفة التوليد مرة واحدة بتبقى قليلة جدًا، وده بيخلّي الـ deterministic tests تـ scale بكفاءة.

أما الـ agent فبيدفع التكلفة دي في كل run، لأن كل خطوة بتتضمن:

1. يبص على حالة الـ UI
2. يفكّر في الخطوة الجاية
3. ينفّذ ويتحقق من النتيجة

3) المرونة — Adaptability

تقريبًا ~20% من الـ runs مشيت بنفس تسلسل الخطوات بالظبط، وفي الباقي، الـ agent اكتشف طرق UI مختلفة (كلها صح) قدر يوصل بيها لنفس الهدف.

عشان يقيسوا ده، قارنوا حاجة اسمها action signature = القايمة المرتبة لكل الـ tool calls و الـ UI actions اللي عملها الـ agent. طبّعوها (normalized) قبل المقارنة عشان يحسبوا الفروق.

النتيجة: معظم التسلسلات كانت مختلفة حتى لما النتيجة النهائية صح. ده بيوضّح الفرق الجوهري — الـ E2E التقليدي بيفرض رحلة واحدة deterministic، والـ agent بيستكشف الواجهة ويتأكد إن الهدف لسه ممكن يتحقق.

4) التكلفة — Cost

التكلفة كانت أبرز حاجة، فالـ agent runs كلّفت 15–30 دولار للـ run، مقارنة بالـ tests التقليدية الأرخص بكتير .. وعشان يفهموا التكلفة دي سببها ايه وجاية منين، حلّلوا الـ token usage لنفس الـ search flow:

المفاجأة اللي لاحظوها هي إن: إزاي الـ agent اشتغل أهم من ايه نوع الـ model اللي استخدمه علشان ينفذ الشغل. فكل طرق الـ MCP استهلكت tokens أقل من الـ CLI والـ Code Gen لنفس الـ flow.

طب ليه؟ ده لإن الـ API اللي وراه stateless — كل مرة بيعيد إرسال الـ system prompt كامل + تاريخ المحادثة كله .. يعني التكلفة مش جاية من مخرجات الـ model (اللي تعتبر تافهة)، ولكن من سرعة تراكم الـ context وعدد الـ turns اللي الـ agent محتاجها.

الـ CLI أخد 85 turn مقابل ~40–60 للـ MCP، لأن كل تفاعل مع المتصفح كان بينقسم على أوامر متعددة (action, wait, snapshot, read, lookup). الـ MCP بيجمّع التفاعل ويرجع الـ state في round trip واحدة.

طب إيه اللي بيملأ الـ context ده؟ في الـ MCP و CLI، الـ browser snapshots هي الحمولة الأساسية (الـ Playwright MCP بيرجّع accessibility tree snapshots بتتراكم في نافذة المحادثة) .. بينما في الـ Code Gen، الـ context الزيادة جاية من مخرجات الـ test runner زي (error traces، assertion failures، DOM state) في كل محاولة إعادة.

الخلاصة: أكبر عوامل التكلفة هي عدد الـ turns ومعدل نمو الـ context — مش تفكير الـ model ولا مخرجاته.

فرص تقليل التكلفة اللي ذكروها: prompt caching، context compaction، وتقليل تكرار الـ snapshots.

وعشان كده، الـ agent-driven testing حاليًا أنسب للـ debugging المحدد أو الـ exploratory testing أكتر من الـ CI عالي التكرار — بس ده ممكن يتحسّن مع الـ models والأدوات الجاية.

الـ Infrastructure بتفرق — MCP vs CLI

خلاصة مهمة تانية: بيئة التنفيذ بتأثر على الـ reliability، مش الـ model بس.

معظم فشل الـ CLI جه من الـ authentication والـ navigation (أخطاء sign-in، timeouts، عدم استقرار session) — يعني من طبقة التنفيذ، مش من تفكير الـ agent.

الـ Playwright MCP بيوفّر primitives منظّمة للمتصفح وتكامل أوثق مع الـ tool-calling بتاع الـ agent، بينما الـ CLI بيحط طبقات زيادة بين الـ agent والمتصفح.

والـ parallelization كمان اختلف: الـ MCP سهل تشغّله بالتوازي، الـ CLI كان صعب، ومعظمه اتشغّل بالتتابع (sequentially).

ودي نقطة مهمة لإن أغلب الناس في الفترة الأخيرة بيتجهوا لاستعمال الـ CLI وشايفين إنه دايمًا أفضل وأسرع واقل تكلفة.

حدود القدرة — Execution Capability Boundaries

التجارب ركّزت على workflows بـ session واحد. السيناريوهات الأعقد (زي cross-workspace flows أو اللي بتفتح أكتر من نافذة متصفح) ليها تحديات مختلفة:

• الـ MCP ممكن يواجه مشاكل في التكلفة كل ما الـ observation loops تطول.
• الـ CLI ممكن يواجه تعقيد تنسيق زيادة لما يدير أكتر من session، بالإضافة للـ tokens العالية أصلًا.

طيب الـ Agentic Testing مكانه فين في الـ Testing Pyramid؟

الإجابة المهمة: مش هيحل محل الطرق الموجودة — ولكنه بيضيف قدرة جديدة فوقها فنقدر نعتمد عليه ونفكر في بيئة الشغل اللي شغالين بيها ازاي نقدر نستغل امكانيته لو بتتناسب مع اللي عاوزين نحققه.

Deterministic E2E Tests

دي بتكون الأنسب للـ regression checks السريعة والمتكررة في الـ CI:

• سواء مكتوبة بإيد بني آدم أو مولّدة بالـ AI
• سريعة، متكررة، وصديقة للـ CI
• تكلفة تشغيل منخفضة
• بتفرض رحلة محددة في الـ UI

Agentic Testing

بتشتغل من خلال تحديد هدف: فتبص على الـ UI، تفكّر في الحالة الحالية، وتقرر إزاي توصل للنتيجة .. وهي بتكون الأنسب لـ:

• استكشاف سلوك UI معقّد
• عمل debug للـ workflows اللي بتكون (flaky)
• إعادة إنتاج bugs في الـ production

Testing Pyramid with Agentic Layer

من منظور النظام، الـ agentic testing لسه بيشتغل على نفس مستوى الـ E2E — بيتحقق من workflows حقيقية عبر الـ UI، ولكن الفرق في إزاي الـ workflows دي بتتنفّذ.

الخلاصة: أفضل استراتيجيات الـ testing في المستقبل هتجمع بين الاتنين. الـ deterministic tests بتوفّر أساس ثابت للـ CI، والـ agentic testing بتضيف طبقة مميزة فوق الهرم للاستكشاف، والـ debugging، والتحقق من السلوكيات المعقّدة.

في الختام

1. الـ Tests بتفرض رحلة، بينما الـ Agents بتتحقق من الهدف — وده الفرق الجوهري.
2. الـ Playwright MCP طلع الأكثر reliability والأقل tokens — لأنه بيحافظ على state حي و context متراكم بذكاء.
3. التكلفة الحقيقية جاية من عدد الـ turns ونمو الـ context، مش من ذكاء الـ model.
4. الـ agent-driven حاليًا مكلّف وبطيء للـ CI (15–30$ و+10 دقايق)، فالأنسب له الـ exploratory testing والـ debugging.
5. منقدرش نعتبره بديل — ولكنه طبقة رابعة جديدة فوق الـ testing pyramid.