اختبار التوافق

لماذا يهم

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

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

التوافق في ⁦ISO/IEC 25010⁩

يصف ⁦ISO/IEC 25010:2023⁩ التوافق بأنه درجة قدرة المنتج على تبادل المعلومات مع منتجات أخرى، أو أداء وظائفه وهو يشاركها بيئة وموارد مشتركة، أو كليهما. ويذكر منهج ISTQB للمستوى التأسيسي التوافق ضمن الخصائص التي يقيّمها الاختبار غير الوظيفي. وكل واحدة من خاصيتيه الفرعيتين، ومن الخاصية التي تضم دعم المنصات، ومن العلاقة بين الإصدارات، تقود إلى نوع مختلف من الاختبار:

• قابلية التشغيل البيني (Interoperability): تتبادل الأنظمة المعلومات وتستطيع استخدام ما تبادلته. فوصول الملف لا يكفي؛ يجب أن يقرأ المستقبِل المبالغ والتواريخ والرموز بالمعنى الذي قصده المرسِل.
• التعايش (Co-existence): يؤدي المنتج وظائفه وهو يشارك بيئةً وموارد مع منتجات أخرى دون أن يضرّها. فعليه أن يصمد بين جيرانه وألا يعطّلهم.
• المرونة (Flexibility): تغطي قابلية التكيّف (Adaptability) العمل على أنظمة تشغيل ومتصفحات وأجهزة أخرى؛ وتغطي قابلية التثبيت (Installability) وقابلية الاستبدال (Replaceability) تثبيت المنتج وحلول إصدار جديد محل إصدار قديم، وهنا مكان اختبار الترقية.
• التوافق مع الإصدارات السابقة والتوافق المستقبلي (Backward and Forward Compatibility): ليس في المعيار مصطلح مستقل للتوافق بين إصدارات المنتج الواحد. وهو عملياً قابلية تشغيل بيني بين الإصدارات، مثل تطبيق قديم يتحدث مع خادم جديد، إضافة إلى قابلية الاستبدال.

قابلية التشغيل البيني: اختبر التبادل لا المرسِل وحده

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

• الأنظمة المتصلة: أنشئ سجلاً في منتجك وتحقق منه في النظام الآخر حقلاً حقلاً: المبالغ مع العملة والمنازل العشرية، والتواريخ مع منطقتها الزمنية، ورموز الحالة مقابل رموز المستقبِل، والأسماء العربية سليمة. ثم المسارات السلبية (Unhappy Paths): الشريك بطيء، أو يرفض السجل، أو يستلمه مرتين.
• صيغ الاستيراد والتصدير: افتح ملفات التصدير في البرامج التي يستخدمها العملاء فعلاً، واستورد الملفات التي تنتجها تلك البرامج. غيّر الترميز (UTF-8 مع علامة ترتيب البايتات BOM وبدونها)، والفاصل (يصف RFC ⁦4180⁩ ملفات CSV مفصولة بفواصل، لكن برامج الجداول في المناطق التي تستخدم الفاصلة العشرية تكتب غالباً فاصلة منقوطة)، وصيغ التواريخ والأرقام، وفواصل الأسطر داخل الحقول المقتبسة، وملفاً فارغاً.
• إصدارات الواجهة البرمجية والمخطط: قارن العقد القديم بالجديد، مثل وصف OpenAPI (قائمة مقروءة آلياً بنقاط النهاية في الواجهة وحقولها) أو مخطط JSON Schema للاستجابة (القواعد التي يجب أن تتبعها حقولها). إضافة حقل اختياري آمنة عادةً؛ أما حذف حقل أو إعادة تسميته، أو تغيير نوعه، أو جعل حقل اختياري في الطلب إلزامياً، أو إضافة قيمة إلى تعداد (enum)، فقد يعطّل تطبيقات عميل صدرت بالفعل. أعد إرسال طلبات العميل السابق كما هي دون تغيير.
• تكاملات الأطراف الثالثة: مزوّدو الدفع والخرائط وتسجيل الدخول والرسائل النصية يغيّرون خدماتهم وفق جدولهم الخاص. اختبر في بيئة الاختبار المعزولة (Sandbox) لدى المزوّد على إصدار الواجهة البرمجية الذي يثبّته منتجك، واقرأ سجل التغييرات وإشعارات الإيقاف التدريجي (Deprecation)، وتحقق مما يفعله منتجك حين يكون المزوّد متوقفاً.

Pharmacy order response, v1 (read by every released app)
{ "id": "A-1042", "total": 149.5, "deliveryDate": "2026-10-04" }

Pharmacy order response, v2 (proposed)
{ "id": "A-1042", "total": "149.50", "currency": "SAR",
  "delivery": { "date": "2026-10-04", "slot": "AM" } }

Change                        Effect on released clients
"currency" added              usually safe if clients ignore unknown fields
"total" number -> string      breaking: arithmetic and validation fail
"deliveryDate" moved          breaking: the field old clients read is gone

جرّبها: مقارنة عقود الاستجابات جرّبها: مدقّق JSON Schema جرّبها: مولّد مجموعات بيانات CSV

التعايش: مشاركة البيئة

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

• الموارد المشتركة: كاميرا أو ميكروفون أو مخرج صوت يستخدمه تطبيق آخر؛ ملف أو منفذ أو طابعة يحجزها برنامج آخر؛ مساحة تخزين أو ذاكرة منخفضة؛ قاعدة بيانات أو طابور رسائل مشترك مع خدمات أخرى. يجب أن ينتظر منتجك أو يشرح أو يتعافى، وأن يحرّر ما أخذه.
• البرمجيات الأخرى: برنامج مكافحة فيروسات يفحص ملفاتك، وشبكة VPN تغيّر الاتصال، وقارئ شاشة، ومكالمة هاتفية تقاطع عملية دفع.
• إضافات المتصفح: قد تخفي أدوات حجب الإعلانات عناصر تطابق قوائم التصفية لديها، مثل شريط له صنف CSS باسم ad-banner؛ ويُدرج مديرو كلمات المرور وأدوات الترجمة أيقونات أو يعيدون كتابة النص؛ وتعيد إضافات الوضع الداكن تلوين الصفحات. اختبر الرحلات الحرجة مع الإضافات التي يذكرها المستخدمون، في ملف تعريف مستقل للمتصفح.
• الإصدارات المتجاورة: إصداران مثبتان على حاسوب واحد، أو نسخة اختبار بجوار نسخة المتجر على هاتف واحد، أو تبويبان يشغّل أحدهما تطبيق الويب القديم بعد النشر. تحقق من الإعدادات والملفات والتخزين المحلي المشتركة، ومن الإصدار الذي يفتح الرابط.

سياسة الدعم والتوافق مع الإصدارات السابقة واللاحقة

لا يحدّث المستخدمون تطبيقاتهم معاً. ففي يوم الإطلاق يلتقي الخادم الجديد بكل إصدار مثبت من التطبيق، وبأجهزة على أقدم نظام تشغيل مدعوم، وببيانات كتبتها الإصدارات السابقة. وتحدد سياسة الدعم المكتوبة ما يجب أن يعمل من ذلك: أدنى إصدارات أنظمة التشغيل، والمتصفحات، وعدد إصدارات التطبيق التي ما زال الخادم يخدمها (غالباً الحالي والسابق، ⁦N⁩ و⁦N-1⁩) وإلى متى، وما يراه المستخدم غير المدعوم، مثل دعوة واضحة للتحديث بدلاً من خطأ صامت.

التوافق مع الإصدارات السابقة (Backward Compatibility) يعني أن الإصدار الجديد يعمل مع ما أنتجته الإصدارات الأقدم ومع تطبيقات العميل الأقدم التي ما زالت مستخدمة. والتوافق المستقبلي (Forward Compatibility) هو الصورة المعكوسة: إصدار أقدم يتعامل مع بيانات إصدار أحدث، عادةً بتجاهل الحقول التي لا يعرفها؛ وعليه يعتمد التراجع عن الإصدار (Rollback). اختبر مسارات الترقية انطلاقاً من العالم القديم، لا من تثبيت نظيف فقط:

• بيانات قديمة وشيفرة جديدة: نفّذ الترقية على حسابات واقعية (طلبات، وعناوين محفوظة، ونموذج نصف مكتمل)، وافتح التصديرات والإشارات المرجعية القديمة. يجب أن يبقى كل شيء موجوداً وصحيحاً وقابلاً للاستخدام.
• تطبيقات عميل قديمة وخادم جديد: شغّل كل إصدار مدعوم من تطبيق العميل، دون تغيير، مقابل الخادم الجديد، وتحقق من دعوة التحديث في أول إصدار غير مدعوم.
• ترحيل الإعدادات: يجب أن تبقى اللغة وإعدادات الإشعارات وإمكانية الوصول وتسجيل الدخول المحفوظ والتفضيلات سليمة بعد الترقية، بما في ذلك القفز فوق عدة إصدارات، مثل الانتقال من ⁦3.8⁩ إلى ⁦4.2⁩ مباشرة.
• بيانات جديدة وشيفرة قديمة: احفظ بيانات بالإصدار الجديد، ثم تراجع عنه أو افتحها في تطبيق العميل السابق؛ يجب أن يتجاهل الإصدار القديم ما لا يعرفه، لا أن ينهار أو يكتب فوقه.

جرّبها: مقارنة JSON

مثال تطبيقي: مصفوفة تغطية واحدة من بيانات الاستخدام

سلسلة صيدليات تبيع عبر موقع إلكتروني وتطبيقين لنظامَي Android وiOS. يغيّر الإصدار ⁦4.2⁩ واجهة الطلبات البرمجية ويضيف موعداً للتوصيل؛ وبعد مقارنة العقود في قسم قابلية التشغيل البيني أبقى الفريق total رقماً وأبقى deliveryDate، فتظل تطبيقات العميل الصادرة قادرة على قراءة الاستجابة. وبدلاً من قوائم منفصلة، يبني المختبِر مصفوفة تغطية توافق واحدة يأتي كل صف فيها من دليل: تحليلات ⁦90⁩ يوماً، وترويسة إصدار العميل في سجل الواجهة البرمجية، وإحصاءات الإصدارات في متجرَي التطبيقات، وقائمة التكاملات، وتذاكر الدعم. ويحصل كل صف على عمق اختبار، ويُكتب ما تُرك، وتُجمع المعاملات المتبقية داخل الصف، مثل اللغة وطريقة الدفع، بالاختيار الزوجي (Pairwise) بحيث يظهر كل زوج من القيم في اختبار واحد على الأقل، كما في درس الاختبار الزوجي. الأرقام توضيحية.

وتعيد صفوف المنصات استخدام عمل سابق بدلاً من تكراره: يقدّم درس الاختبار المتجاوب (Responsive Testing) عروض منفذ العرض ونقاط التوقف، ويقدّم درس الاختبار عبر المتصفحات (Cross-Browser Testing) المحركات وطبقات الدعم (Tiers): تُشغَّل على الطبقة 1 الرحلات الحرجة وحزمة الانحدار مع كل إصدار، وعلى الطبقة 2 اختبار دخان للرحلات الحرجة، وعلى الطبقة 3 فحوص بأفضل جهد فقط؛ ويبيّن درس تجزؤ الأجهزة (Device Fragmentation)، لاحقاً في وحدة اختبار تطبيقات الجوال، كيف تُختار الهواتف. وتضيف هذه المصفوفة ما لا تغطيه تلك الدروس: إصدارات العميل، والأنظمة المتصلة، والصيغ، والجيران، والترقية، لتجيب صفحة واحدة عن سؤال: ماذا اختبرنا، ومقابل ماذا، وماذا تركنا؟ وقد كشفت الخطة ثلاثة عيوب:

• تطبيق قديم وخادم جديد: التطبيق ⁦4.1⁩، الذي يأتي منه ⁦31%⁩ من الطلبات، لا يرسل حقل deliverySlot الجديد في طلب إنشاء الطلبية (أما الاستجابة فتعيد الموعد في delivery.slot). وتعامل الواجهة ⁦4.2⁩ الحقل على أنه إلزامي وتردّ بـ 400 Bad Request بدلاً من تطبيق القيمة الافتراضية، وهو الكسر من جهة الطلب الذي يحذّر منه قسم قابلية التشغيل البيني. وهذا يوقف الإطلاق.
• قابلية التشغيل البيني: يكتب التصدير الجديد إلى نظام المخزون التواريخ بصيغة 04/10/2026 واليوم أولاً، فيقرؤها نظام المخزون على أنها ⁦10⁩ أبريل. نجح النظامان في اختباراتهما الخاصة، ولم يكشف العيب إلا الفحص حقلاً حقلاً.
• التعايش: تضع إضافة شائعة لإدارة كلمات المرور أيقونتها فوق زر إظهار كلمة المرور في صفحة تسجيل الدخول. لا يخطئ أي من المنتجين وحده، فينقل الفريق الزر.

Release 4.2 compatibility coverage matrix (illustrative numbers, last 90 days)

Area          Row                                     Evidence          Depth
Platforms     Tiers 1 and 2, cross-browser plan       analytics         per tier
              Android: oldest supported, current      store statistics  critical journeys
              iOS: previous and current               store statistics  critical journeys
Clients       app 4.2 (new)                           -                 full regression
              app 4.1 (31% of orders)                 API client log    critical journeys
              app 4.0 and older (2%, unsupported)     API client log    update prompt
Interop       payment provider, pinned API version    integration list  pay, fail, refund
              stock system export (CSV)               integration list  field by field
              SMS provider                            integration list  send, outage
Co-existence  password-manager extension              support tickets   sign-in journey
Upgrade       4.0 and 4.1 to 4.2, real accounts       -                 data, settings
Rollback      4.2 data opened in app 4.1              -                 forward check
Left out (recorded in the test plan): Firefox on Android (0.3%), tablets in landscape

جرّبها: مولّد الاختبار الزوجي (Pairwise) جرّبها: محلّل User-Agent

أسئلة شائعة

المراجع

• ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelISO/IEC · 2023نموذج جودة المنتج: الملاءمة الوظيفية وكفاءة الأداء والتوافق وقابلية التفاعل والموثوقية والأمان وقابلية الصيانة والمرونة.
• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• OpenAPI SpecificationOpenAPI Initiativeالمعيار لوصف واجهات REST: المسارات والعمليات والمعاملات والمخططات والاستجابات وأنظمة الأمان.
• RFC 4180: Common Format and MIME Type for Comma-Separated Values (CSV) FilesIETF · 2005قواعد CSV الشائعة: الفاصلة كفاصل، ونهايات الأسطر CRLF، وتحويط الحقول التي تحتوي فواصل أو علامات اقتباس أو أسطر جديدة.