Slack Ran 200+ Agentic Tests: Testing E2E Workflows with Agents

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

Jul 18, 2026

∙ Paid

لا تنسوا أهلنا من صالح الدعاء,‏اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸 🇸🇩

سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هتساعدك على مواكبة أحدث تطورات عالم البرمجة بمواضيع جديدة كل أسبوع، هتلاقى كمان محتوى عملي بيشمل أفضل الممارسات، ونصائح مفيدة، وترشيحات لمقالات مختارة من اقرأ-تِك.

فريق الـ 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 ده بيوضّح الفرق:

Agent-Driven Test vs Traditional E2E Test

في تجارب 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

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

الـ Agent + Playwright MCP: الـ agent بيتعامل مع المتصفح من خلال الـ Playwright MCP، بيستخدم أوامر جاهزة (دوس على element، اكتب input، اقرا الـ DOM state...) مع الاحتفاظ بالـ context (snapshots و logs).
الـ Generated Playwright Tests: هنا الـ agent بياخد وصف بلغة عادية جدًا، ويكتب كود Playwright حقيقي (deterministic)، يشغّله كـ E2E test عادي، ويظبطه شوية بشوية لحد ما ينجح.
الـ 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.