الاختبار من البداية إلى النهاية

لماذا يهم

كثير من الإخفاقات الخطيرة يقع بين الأنظمة لا داخلها: يُدفع الطلب، لكن المستودع لا يُبلَّغ به أبداً. قد ينجح كل مكوّن وكل واجهة برمجية (API) في اختباراته، ومع ذلك لا يستطيع العميل إتمام الشراء. ولا يرى ما يراه المستخدم إلا اختبار يتتبع الرحلة كلها.

من منظور الأعمال، الرحلات الحرجة مثل التسجيل وإتمام الشراء والدفع هي المواضع التي تكلّف فيها الإخفاقات الإيرادات والثقة مباشرةً. ومن منظور المختبِر، تقدّم اختبارات E2E أقوى دليل على أن الإصدار قابل للاستخدام، وهي في الوقت نفسه أغلى الاختبارات بناءً وصيانةً وتشغيلاً. لذا فإن تحديد ما يستحق اختبار E2E مهارة أساسية.

ما الذي يغطيه اختبار E2E

يُعرَّف اختبار E2E برحلة، لا بشاشة ولا بمكوّن. يبدأ من حيث يبدأ المستخدم، وينتهي حيث يتحقق هدفه ويصبح ظاهراً: الطلب شُحن، والمال وصل إلى الحساب الآخر. وقيمته الحقيقية في نقاط التحقق عند الانتقالات (Hand-offs)، أي حيث تنتقل الرحلة من نظام إلى آخر.

• البداية والنهاية: فاعل واحد، وهدف واحد، ونتيجة نهائية يمكن التحقق منها.
• الأنظمة: الواجهة الأمامية، والخدمات الخلفية، وقاعدة البيانات، وطوابير الرسائل، وخدمات الأطراف الثالثة، على أن تكون أنظمتك أنت بالإصدارات التي تنوي إطلاقها.
• نقاط التحقق: الحالة بعد كل انتقال، مثل حالة الطلب أو مرجع الدفع أو رسالة البريد التي أُرسلت.

الفرق بين اختبار E2E واختبار النظام

في منهج ISTQB للمستوى التأسيسي، اختبار النظام (System Testing) مستوى اختبار يركّز على السلوك العام لنظام كامل وقدراته، وكثيراً ما يشمل الاختبار الوظيفي لمهام من البداية إلى النهاية داخل هذا النظام. ويمكن محاكاة الأجزاء التي يعتمد عليها، أما الواجهات مع الأنظمة الأخرى والخدمات الخارجية فهي محور مستوى مستقل هو اختبار تكامل الأنظمة (System Integration Testing). ويصف مسرد ISTQB الاختبار من البداية إلى النهاية بأنه نوع اختبار لا مستوى اختبار: تحدّد نطاقَه عمليةُ أعمالٍ تعبر كل الأنظمة المعنية، ومنها أنظمة لا يملكها فريقك.

يتداخل الاثنان، وكثيراً ما تُنفَّذ اختبارات E2E أثناء اختبار النظام أو اختبار تكامل الأنظمة أو اختبار القبول. وبعض الفرق تسمّي أي اختبار آلي يعمل عبر المتصفح «E2E»، حتى لو غطّى صفحة واحدة مع محاكاة الواجهة الخلفية (Back End)؛ فإذا سمعت المصطلح، فاسأل: ما الذي كان حقيقياً وما الذي جرت محاكاته؟

• النطاق: نظام واحد كامل، مقابل رحلة أعمال واحدة أينما ذهبت.
• الأنظمة المجاورة: يمكن أن تُحاكى في اختبار النظام؛ وفي اختبار E2E تكون حقيقية، أو أقرب بديل متاح مثل بيئة Sandbox لدى المزوّد.
• العيوب المعتادة: سلوك خاطئ داخل النظام، مقابل انتقالات معطّلة وصيغ بيانات غير متطابقة وخطوات مفقودة بين الأنظمة.

مثال تطبيقي: طلب إلكتروني من السلة إلى الشحن

يتكوّن متجر إلكتروني من متجر ويب (واجهة أمامية وخدمة طلبات) يبنيه فريقك، ومزوّد دفع في وضع الاختبار، ونظام مستودع يديره فريق آخر، وخدمة بريد إلكتروني. الرحلة: عميل مسجَّل يشتري منتجين ثم يُشحن الطلب. ورقم الطلب الواحد هو ما يربط كل عمليات التحقق.

• عمليات التحقق من ⁦3⁩ إلى ⁦6⁩ في حالة الاختبار أدناه هي ما يجعلها اختبار E2E: كلٌّ منها يقرأ الحالة على الجانب الآخر من انتقال (من الدفع إلى خدمة الطلبات، ومن خدمة الطلبات إلى البريد، ومن خدمة الطلبات إلى المستودع، ومن المستودع عائداً إلى متجر الويب). ولو اقتصر الاختبار على التحققين ⁦1⁩ و⁦2⁩ لما أظهر إلا ما تعرضه شاشة العميل.
• إذا فشل التحقق ⁦5⁩ ونجح التحقق ⁦3⁩، فاشتبه في الانتقال من خدمة الطلبات إلى المستودع، وسجّل الملاحظتين كلتيهما في تقرير الخطأ.

E2E-01  عميل مسجَّل يشتري منتجين ويُشحن الطلب

الشروط المسبقة:
- العميل e2e.0412@example.com موجود وحسابه مُفعَّل
- المنتج A (75.00 ريال، المخزون 10) والمنتج B (40.00 ريال، المخزون 3)
  موجودان في متجر الويب وفي نظام المستودع
- مزوّد الدفع في وضع الاختبار
- رسائل البريد الصادرة من بيئة الاختبار تصل إلى صندوق بريد الاختبار

الخطوات والتحقق:
1. سجّل الدخول، وأضف 2 x A و1 x B إلى السلة.
   تحقّق: المجموع الفرعي 190.00 ريال.
2. أكمل الشراء وادفع ببطاقة الاختبار التي ينشرها المزوّد للدفع المقبول.
   تحقّق: صفحة التأكيد تعرض رقم الطلب.
3. تحقّق: خدمة الطلبات تحفظ الطلب بالحالة PAID مع مرجع الدفع؛
   مخزون A أصبح 8 ومخزون B أصبح 2.
4. تحقّق: رسالة التأكيد برقم الطلب نفسه موجودة في صندوق بريد الاختبار.
5. تحقّق: نظام المستودع استلم الطلب بالأصناف الثلاثة نفسها.
6. في نظام المستودع، علّم الطلب بأنه شُحن.
   تحقّق: صفحة الطلب لدى العميل تعرض «تم الشحن» ورقم تتبع.

جرّبها: قصة المستخدم ← سيناريوهات اختبار

لماذا تبقى اختبارات E2E قليلة

تقع اختبارات E2E في قمة هرم الاختبار (Test Pyramid)، وهو نموذج يصفه منهج ISTQB ومقال «The Practical Test Pyramid» على موقع martinfowler.com. ويصوّر الهرم مجموعة اختبارات سليمة: اختبارات كثيرة صغيرة وسريعة ومعزولة في القاعدة (اختبارات المكوّنات)، واختبارات تكامل أقل في الوسط، وعدد قليل فقط من اختبارات E2E في القمة؛ وتختلف النماذج في عدد الطبقات وأسمائها. وكلما ارتفع الاختبار في الهرم غطّى أكثر في التشغيل الواحد، وصار أبطأ وأقل عزلاً وأعلى كلفة في الصيانة. وعندما يفشل اختبار E2E، قد يكون السبب في أي نظام مرّ به.

لذلك اختبر كل قاعدة في أدنى مستوى يمكن اختبارها فيه، واحتفظ بمجموعة صغيرة من اختبارات E2E للرحلات الأهم للأعمال.

• اختر حسب المخاطر: تستحق الرحلة اختبار E2E عندما يمنع إخفاقها المستخدمين من بلوغ هدف مهم أو يكلّف مالاً.
• غطِّ المسار الرئيسي وبعض البدائل المهمة فقط، مثل رفض الدفع.
• إذا كشف اختبار E2E عيباً لم يكشفه أي اختبار في مستوى أدنى، فأضف له اختباراً أسرع في مستوى أدنى، مثل اختبار مكوّن أو اختبار API، بدلاً من إضافة مزيد من اختبارات E2E.

جرّبها: مولّد الاختبار المبني على المخاطر

تحديات بيانات الاختبار وبيئة الاختبار

يذهب جزء كبير من جهد اختبار E2E إلى البيانات والبيئات. فالبيانات يجب أن تكون متسقة في عدة أنظمة في آن واحد، وكل تشغيل يغيّرها: ينقص المخزون وتتراكم الطلبات. والبيئة يجب أن تضم كل الأنظمة بإصدارات متوافقة؛ والبيئات المشتركة كثيراً ما تكون مزدحمة أو متأخرة بإصدار، وبيئات Sandbox لدى الأطراف الثالثة قد تكون بطيئة أو غير متاحة.

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

جرّبها: مصنع بيانات الاختبار جرّبها: بريد إلكتروني مؤقت

أسئلة شائعة

المراجع

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• ISTQB GlossaryISTQBالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
• The Practical Test Pyramid (Ham Vocke)martinfowler.com · 2018شرح واسع الاستشهاد لكيفية الموازنة بين اختبارات الوحدة والتكامل والعقود والواجهة في محفظة الاختبارات الآلية.
• Eradicating Non-Determinism in Tests (Martin Fowler)martinfowler.com · 2011لماذا تُفقد الاختبارات المتذبذبة الحزمةَ قيمتها، وأسبابها الشائعة (العزل وعدم التزامن والخدمات البعيدة والوقت وتسرّب الموارد)، والحجر كاستجابة.