الاختبارات المتذبذبة

ما الاختبار المتذبذب، ولماذا يهم

يكون الاختبار متذبذباً عندما تعطي التشغيلات المتكررة على الإيداع (commit) نفسه وإعدادات البيئة نفسها نتائج مختلفة. شغّله عشر مرات فقد ينجح ثماني مرات ويفشل مرتين. ولأن النتيجة غير حتمية فلا تخبرك أي نتيجة بمفردها بالكثير عن المنتج.

وكلفته أكبر بكثير من معدل حدوثه. فكل فشل متذبذب يكلّف أحداً تحقيقاً أو إعادة تشغيل؛ وبعد بضع مرات يبدأ الفريق بمعاملة كل فشل كضجيج. ومقال Martin Fowler عن عدم الحتمية في الاختبارات يقولها صراحة: الحزمة التي تفشل عشوائياً تفقد قيمتها كإشارة. وليس الاختبار المتذبذب دائماً اختباراً سيئاً — فأحياناً تكون حالة السباق (Race condition) في المنتج نفسه، والاختبار هو الوحيد الذي لاحظها.

• الاختبار نفسه يفشل في تشغيل وينجح عند إعادة التشغيل، دون أي تغيير في الشيفرة بينهما.
• يفشل في CI فقط، أو عند التوازي فقط، أو في أوقات معينة من اليوم، أو في متصفح واحد فقط.
• رسالة الفشل تتغير بين التشغيلات — انتهاء مهلة في أحدها، و«العنصر غير موجود» في التالي.

الأسباب الشائعة لتذبذب اختبارات الواجهة

• التوقيت وعدم التزامن — التصرف أو التحقق قبل جاهزية الصفحة: النقر على زر ما زال معطّلاً، أو قراءة نص قبل وصول استجابة API، أو انتظار ثابت يكون أحياناً أقصر من اللازم.
• الحالة المشتركة وترتيب الاختبارات — اختبارات تعتمد على بيانات أو حالة متصفح أنشأها اختبار آخر أو غيّرها. تنجح بترتيب وتفشل بآخر، أو تفشل عند تشغيلها منفردة.
• تصادم بيانات الاختبار — اختبارات متوازية تستخدم الحساب نفسه أو البريد نفسه أو مخزون المنتج نفسه؛ وقيود تفرّد تفشل عندما يختار تشغيلان القيمة «العشوائية» نفسها.
• البيئة — خادم CI محمّل فوق طاقته، أو بيئة اختبار مشتركة يُعاد نشرها أثناء التشغيل، أو بدء بطيء للحاويات، أو حجم شاشة أو لغة أو منطقة زمنية مختلفة على الخادم.
• خدمات الأطراف الثالثة والخدمات البعيدة — بيئات اختبار الدفع، وبوابات الرسائل النصية، وبلاطات الخرائط، وخدمات أعلام الميزات، وشبكات CDN البطيئة أو غير المتاحة أو المحدودة المعدل.
• الحركات والانتقالات — النقر على عنصر أثناء انزلاقه إلى مكانه، أو التحقق من إشعار منبثق يختفي بعد ثوانٍ.
• الوقت والتواريخ — اختبارات تنكسر حول منتصف الليل ونهايات الأشهر وتغييرات التوقيت الصيفي، أو عندما تختلف المنطقة الزمنية للخادم عن منطقة التطبيق.
• بيانات غير مرتبة — التحقق من الصف الأول في قائمة يعيدها الخادم دون ترتيب مضمون.
• تسرّب الموارد — متصفحات أو جلسات أو اتصالات قاعدة بيانات لا تُغلق، فتتباطأ الاختبارات اللاحقة في التشغيل الطويل أو تفشل.
• عيوب حقيقية في المنتج — حالات سباق، وإرسال مزدوج، وذاكرة تخزين مؤقت لا تُبطَل. هذه أخطاء يُبلَّغ عنها، لا ضجيج اختبارات يُحجر.

الأعراض والأسباب الجذرية: أمثلة عملية

يقرن الجدول أعراضاً متذبذبة نموذجية، مكتوبة كما تظهر في متتبّع العيوب، بالسبب الجذري الذي كشفه التحقيق والإصلاح الذي أزاله. لاحظ أن أياً من الإصلاحات ليس «أضف انتظاراً أطول» ولا «فعّل إعادة المحاولة».

• checkout.spec: النقر على «Place order» يُتجاهل في نحو تشغيل من كل 10 ← السبب: الزر لا يُفعَّل إلا بعد إعادة حساب السعر ← الإصلاح: تحقّق من حالة التفعيل واعتمد على الانتظار التلقائي.
• orders.spec يفشل فقط عند تشغيله بعد refunds.spec ← السبب: refunds.spec يلغي الطلب المشترك ← الإصلاح: كل اختبار يُنشئ طلبه الخاص عبر API.
• signup.spec: رسالة «email already registered» في تشغيلات CI المتوازية ← السبب: عاملان يولّدان البريد نفسه ← الإصلاح: أضف معرّف التشغيل/العامل وUUID إلى البيانات المولّدة.
• report.spec يفشل بين 00:00 و03:00 بتوقيت الرياض ← السبب: المشغّل يستخدم UTC فيختلف «اليوم» ← الإصلاح: تحكّم في الساعة أو احسب التواريخ في منطقة زمنية واحدة.
• profile.spec: إشعار «Saved» لا يُعثر عليه في CI فقط ← السبب: الإشعار يختفي قبل التحقق البطيء ← الإصلاح: تحقّق من الحالة المحفوظة لا من الإشعار العابر.
• map.spec تنتهي مهلته تحت الحمل المتوازي ← السبب: خدمة بلاطات الخرائط الخارجية تحدّ معدل الطلبات ← الإصلاح: استبدل استجابات الخرائط باستجابات وهمية واحتفظ بفحص عقد واحد.

For example (fictional):

Symptom (as a bug title)                                         Root cause                                  Fix
checkout.spec: "Place order" click ignored in ~1 of 10 runs      Button enabled only after price recalculated  Assert the enabled state; rely on auto-wait
orders.spec fails only when run after refunds.spec               refunds.spec cancels the shared order         Each test creates its own order via the API
signup.spec: "email already registered" in parallel CI runs      Two workers generate the same email           Add run/worker id + UUID to generated data
report.spec fails between 00:00 and 03:00 Riyadh time            Runner uses UTC, so "today" differs           Control the clock or compute dates in one zone
profile.spec: "Saved" toast not found on CI only                 Toast disappears before the slow assertion    Assert the saved state, not the transient toast
map.spec times out under parallel load                           Third-party tile service rate-limits the run  Stub map responses; keep one contract check

تشخيص اختبار متذبذب

عامل الاختبار المتذبذب كأي خطأ متقطع: أعد إنتاجه، واجمع الأدلة من التشغيلات الفاشلة، وغيّر متغيراً واحداً في كل مرة حتى يتحرك معدل الفشل.

• أعد الإنتاج بالتكرار — شغّل الاختبار المفرد مرات كثيرة (يوفّر Playwright الخيار ‎--repeat-each‎؛ ومع المشغّلات الأخرى استخدم خيار التكرار فيها أو حلقة في الطرفية). فمعدل الفشل يحوّل «يفشل أحياناً» إلى رقم تقارنه قبل الإصلاح وبعده.
• غيّر شرطاً واحداً — منفرداً مقابل ضمن الحزمة كاملة، وتسلسلياً مقابل متوازياً، وترتيباً مختلفاً، ومحلياً مقابل CI، ومعالجاً أو شبكة مخنوقين، ومتصفحاً آخر. الشرط الذي يغيّر معدل الفشل يشير إلى السبب.
• اقرأ الأدلة من التشغيل الفاشل — لقطة الشاشة عند الفشل، والفيديو، والأثر (trace). يعرض عارض الآثار في Playwright كل إجراء مع لقطات DOM وطلبات الشبكة ورسائل وحدة التحكم؛ ويستطيع Cypress التقاط لقطات شاشة وفيديو للتشغيلات؛ ومع Selenium التقط لقطة شاشة وسجلات المتصفح ومصدر الصفحة في خطاف الفشل لدى مشغّلك.
• اربط بالخلفية — سجّل معرّفات الطلبات والطوابع الزمنية التي أنتجها الاختبار وابحث عن النافذة الزمنية نفسها في سجلات الخادم. انتبه للمناطق الزمنية: كثيراً ما تستخدم خوادم CI توقيت UTC بينما يسجّل التطبيق بالتوقيت المحلي.
• راجع التاريخ — تُظهر تقارير الاختبار ولوحات CI متى بدأ التذبذب؛ قارن ذلك التاريخ بالإيداعات وترقيات الاعتماديات وتغييرات البيئة.

// playwright.config.ts — keep evidence from failing runs
export default defineConfig({
  retries: process.env.CI ? 1 : 0,
  use: {
    trace: "on-first-retry",
    screenshot: "only-on-failure",
    video: "retain-on-failure",
  },
});

# reproduce locally: run one spec 50 times with 4 workers
npx playwright test tests/checkout.spec.ts --repeat-each=50 --workers=4

# open the trace from a failed CI run
npx playwright show-trace trace.zip

معالجة الأسباب الشائعة

• التوقيت — استبدل الانتظار الثابت بانتظار مشروط: الانتظار الصريح في Selenium، والإجراءات ذات الانتظار التلقائي والتأكيدات web-first في Playwright، والاستعلامات المعادة مع ‎.should()‎ في Cypress. انتظر إشارة التطبيق نفسه — استجابة أو تغيّر حالة — لا الوقت.
• الحالة المشتركة — اجعل كل اختبار يُنشئ بياناته وحالة متصفحه، ويبدأ من سياق متصفح جديد، ولا يعتمد أبداً على تشغيل اختبار آخر قبله.
• تصادم البيانات — ولّد قيماً فريدة لكل اختبار ولكل عامل؛ وأخرج الحسابات الثابتة مثل «مستخدم الاختبار 1» من التشغيلات المتوازية.
• البيئة — ثبّت إصدارات المتصفحات والاعتماديات، وخصّص للحزمة بيئة مستقلة أو جمّد النشر أثناء التشغيل، واجعل حجم خوادم CI مناسباً لعدد العمّال.
• خدمات الأطراف الثالثة — استبدلها باستجابات وهمية في معظم اختبارات الواجهة (page.route في Playwright، وcy.intercept في Cypress، أو خادم محاكاة) واحتفظ بفحص صغير يُبلَّغ عنه منفصلاً مقابل بيئة الاختبار الحقيقية.
• الحركات — تحقّق من الحالة النهائية لا من حالة عابرة؛ وحيث يحترم التطبيق تفضيل تقليل الحركة (reduced motion) فحاكِه في الاختبارات لتقصير الانتقالات أو إزالتها.
• الوقت — تحكّم في الساعة (واجهة clock في Playwright، وcy.clock في Cypress) أو احسب التواريخ المتوقعة بالمنطقة الزمنية للتطبيق.
• الترتيب — رتّب أو صفِّ صراحةً قبل التحقق؛ ولا تفترض أبداً أن الصف الأول هو ما أنشأه اختبارك.

// Flaky: guesses how long the save takes, then reads the text once
await page.getByRole("button", { name: "Save" }).click();
await page.waitForTimeout(2000);
expect(await page.getByTestId("status").textContent()).toBe("Saved");

// Stable: waits for the app’s own signal and retries the assertion
const saved = page.waitForResponse(
  (r) => r.url().includes("/api/profile") && r.request().method() === "PUT");
await page.getByRole("button", { name: "Save" }).click();
expect((await saved).ok()).toBeTruthy();
await expect(page.getByTestId("status")).toHaveText("Saved");

جرّبها: مولّد مستخدمين وهميين جرّبها: مصنع بيانات الاختبار جرّبها: مولّد استجابات API وهمية جرّبها: منشئ طلبات API

إعادة المحاولة والحجر: احتواء لا علاج

إعادة المحاولة التلقائية (Retries) — إعداد retries في Playwright، وخيار retries في Cypress، وميزات إعادة التشغيل في مشغّلات مثل TestNG وMaven Surefire — تجعل الخط أخضر عندما ينجح اختبار متذبذب في محاولة لاحقة. هذا مقبول كاحتواء قصير الأمد وضار كسياسة: فإعادة المحاولة تُخفي العيوب المتقطعة الحقيقية، وتبطئ الخط، وتترك معدل التذبذب ينمو دون أن يُرى. وإن استخدمتها فاجعلها مرئية؛ فمثلاً يعرض Playwright الاختبار الذي فشل ثم نجح عند إعادة المحاولة على أنه «flaky» لا «passed».

والحجر (Quarantine) هو أداة الاحتواء الأخرى: انقل الاختبار المعروف بتذبذبه من الحزمة التي تمنع الدمج إلى مهمة منفصلة غير مانعة، حيث يستمر في العمل والإبلاغ دون إيقاف الدمج. ويصف Fowler الحجر بأنه وسيلة لإبقاء الحزمة الرئيسية جديرة بالثقة — مع التحذير من أن الاختبارات المحجورة يجب إصلاحها سريعاً، وإلا توقفت عن حماية أي شيء.

• اسمح بمحاولة إعادة واحدة على الأكثر في CI ولا شيء محلياً، وأبلغ عن «نجح عند إعادة المحاولة» على أنه متذبذب.
• تحقّق أولاً مما إذا كان الفشل خطأً في المنتج؛ ولا تحجر عيباً حقيقياً أبداً.
• امنح كل اختبار محجور مالكاً وتذكرة وموعداً نهائياً، وراجع القائمة أسبوعياً.
• حين يتجاوز الاختبار موعده في الحجر: أصلحه، أو أعد كتابته في مستوى أدنى، أو احذفه. فالاختبار المتخطّى دائماً شيفرة ميتة تبدو كتغطية.
• ضع سقفاً للحجر. وإن ظل ينمو فتوقف عن الإضافة إليه وعالج السبب المشترك — وهو عادةً البيئة أو استراتيجية بيانات الاختبار.
• ويضيف مثال السياسة أدناه أرقاماً ملموسة يمكن تكييفها: يصنّف CI الاختبار متذبذباً إذا فشل ونجح على الإيداع نفسه؛ ويُفرز خلال يوم عمل واحد (خطأ في المنتج أم في الاختبار أم في البيئة؟)؛ ولا يتجاوز الموعد النهائي في الحجر 10 أيام عمل؛ ويخرج الاختبار من الحجر بعد إصلاحه و50 نجاحاً متتالياً مع ‎--repeat-each‎، أو بإعادة كتابته أو حذفه؛ وتُراجع قائمة الاختبارات المتذبذبة أسبوعياً مع اتجاه معدل التذبذب لكل حزمة.

Flaky test policy (example)
- Detection:  a test that fails and passes on the same commit is flagged flaky by CI
- Retries:    at most 1 in CI, 0 locally; "passed on retry" is reported as flaky, not passed
- Triage:     within 1 working day: product bug, test bug or environment?
- Quarantine: non-blocking job, with ticket + owner + due date (max 10 working days)
- Exit:       fixed and 50 consecutive passes with --repeat-each, or rewritten / deleted
- Review:     weekly flaky list in the QA sync; flaky-rate trend per suite

الملكية والقياس

تبقى الاختبارات المتذبذبة متذبذبة حين لا يملكها أحد. وزّع الملكية حسب منطقة المنتج — الفريق الذي يملك إتمام الشراء يملك اختباراته — لا على «شخص الأتمتة» الوحيد، واجعل فرز الاختبارات المتذبذبة جزءاً من تعريف الإنجاز (Definition of Done) لا مشروعاً جانبياً.

بضعة مقاييس بسيطة تُظهر ما إذا كان الوضع يتحسن. تتبّعها لكل حزمة وراجع الاتجاه لا أسبوعاً واحداً.

• معدل التذبذب — نسبة تشغيلات الاختبار التي فشلت ثم نجحت عند إعادة المحاولة، أو فشلت دون تغيير في الشيفرة.
• أكبر المتسببين — الاختبارات القليلة المسؤولة عن معظم الإخفاقات المتذبذبة؛ وإصلاحها يعطي عادةً أكبر تحسن.
• زمن الإصلاح — كم يبقى الاختبار موسوماً بالتذبذب أو محجوراً.
• كلفة إعادة التشغيل — دقائق الخط وساعات العمل المصروفة على إعادة المحاولة وإعادة التشغيل اليدوية.

منع التذبذب عند كتابة الاختبارات

• لا انتظار ثابتاً؛ كل انتظار شرط مع مهلة قصوى.
• تأكيدات تعيد المحاولة على نتائج يراها المستخدم، لا قراءات لمرة واحدة.
• محددات متينة مبنية على الدور أو التسمية أو النص أو معرّفات الاختبار — انظر دليل استراتيجيات المحددات.
• كل اختبار يُنشئ بياناته ويملكها، بقيم فريدة لكل تشغيل ولكل عامل.
• تُهيّأ الحالة عبر API، لا بالنقر عبر شاشات لا علاقة لها بالاختبار.
• تُستبدل خدمات الأطراف الثالثة باستجابات وهمية، ويُتحكم في الساعة والمنطقة الزمنية حيث تهم التواريخ.
• تُشغَّل الاختبارات الجديدة مرات كثيرة — مثلاً من 20 إلى 50 تكراراً — قبل انضمامها إلى الحزمة المانعة.
• تعمل الحزمة بالتوازي، وبترتيب عشوائي من حين لآخر، حتى تظهر الاعتماديات الخفية مبكراً.

الأسئلة الشائعة

المراجع

• Eradicating Non-Determinism in Tests (Martin Fowler)martinfowler.com · 2011لماذا تُفقد الاختبارات المتذبذبة الحزمةَ قيمتها، وأسبابها الشائعة (العزل وعدم التزامن والخدمات البعيدة والوقت وتسرّب الموارد)، والحجر كاستجابة.
• Trace viewer — PlaywrightMicrosoft (Playwright)تسجيل تشغيل الاختبار وإعادة عرضه خطوة بخطوة — لقطات DOM والشبكة ووحدة التحكم — لتشخيص الإخفاقات، خصوصاً القادمة من CI.
• Auto-waiting — PlaywrightMicrosoft (Playwright)فحوص الجاهزية التي يجريها Playwright قبل كل إجراء — مرئي، ومستقر، ومفعّل، ويستقبل الأحداث — والتي تُغني عن معظم الانتظارات المكتوبة يدوياً.
• Waiting Strategies — SeleniumSelenium Projectلماذا تتسابق اختبارات المتصفح مع الصفحة، وكيف تزامن الانتظارات الضمنية والصريحة سكربت WebDriver مع التطبيق.
• Best Practices — CypressCypress.ioإرشادات Cypress لاختيار العناصر بسمات مخصّصة، وتجنّب الانتظار الثابت، وإبقاء الاختبارات مستقلة.
• Best Practices — PlaywrightMicrosoft (Playwright)اختبر السلوك الذي يراه المستخدم، واجعل الاختبارات معزولة، وفضّل المحدِّدات المتينة والتأكيدات التي تنتظر، واستخدم التتبّع لتصحيح الأخطاء.