كيف تختبر التكاملات قبل إطلاق مشروع الأرشفة؟

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

لماذا يحتاج التكامل اختبارًا مختلفًا عن بقية النظام؟

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

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

ولذلك تذكر صفحة خطوات تنفيذ التكامل أن البناء والتجربة تشمل الحالات العادية وحالات الخطأ، وأن الجهة ومورد النظام الآخر يشاركان في الاختبار والتحقق من النتائج.

شروط الدخول: ما يجب أن يكون جاهزًا قبل أول حالة

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

1. مواصفة التكامل معتمدة

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

   مالك الإجراء ومدير المشروع
2. بيئتا اختبار متصلتان

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

   تقنية المعلومات ومورد النظام الآخر
3. بيانات اختبار ممثلة ومجهزة مسبقًا

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

   مالك النظام الآخر
4. حساب تكامل بصلاحيات محدودة

   حساب مستقل لكل نظام، بصلاحيات لا تتجاوز ما يحتاجه التكامل، لا حساب مسؤول النظام. الاختبار بحساب واسع الصلاحيات يخفي مشكلات ستظهر في الإنتاج.

   أمن المعلومات
5. أشخاص مسمون من الطرفين

   من يستطيع إطلاق الحدث في النظام الآخر، ومن يقرأ سجلاته، ومن يقرر إن كان الخلل في طرفه. وجودهم في يوم الاختبار نفسه، لا بالبريد بعده.

   مدير المشروع لدى الجهة
6. إصدارات مجمدة

   إصدار كل نظام وإعدادات التكامل ثابتة أثناء دورة الاختبار. تحديث أحد النظامين في منتصفها يعني إعادة الحالات المتأثرة.

   مورد النظامين

جدول حالات اختبار التكامل

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

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

اختبار الحجم من أرقام جهتك لا من أرقام المورد

«التكامل يتحمل أي حجم» عبارة لا تُختبر. الحجم الذي يهمك هو ذروة جهتك، وتستخرجه من سجلات النظام المصدر لا من التقدير:

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

جهة افتراضية وجدت في سجلات نظامها المالي أن أعلى يوم في السنة سُجلت فيه 1,200 فاتورة، أغلبها في آخر أربع ساعات عمل. قرر فريق المشروع أن يختبر بدفعة 1,500 فاتورة، أي الذروة مع هامش ربع إضافي حدده بنفسه، تُطلق خلال أربع ساعات. النتيجة المطلوبة: 1,500 عملية في سجل الربط، و1,500 فاتورة في الأرشيف، ومدة معالجة لا تتجاوز ما اتُّفق عليه في المواصفة. الأرقام هنا لتوضيح الطريقة فقط، والهامش قرار الجهة بحسب توقع نموها.

وإن كانت بيئة الاختبار أضعف من الإنتاج، فاذكر ذلك في محضر النتائج، ولا تستنتج من سرعة الاختبار سرعة الإنتاج ولا العكس. الأهم في اختبار الحجم هو المطابقة وغياب الفقد والتكرار، أما التوقيت فيُقرأ في سياق البيئة.

البيئات: من الاختبار إلى الإنتاج دون مفاجآت

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

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

ضوابط الفصل بين البيئتين نفسها، من البيانات والصلاحيات إلى نقل الإعدادات، تجدها في مقالة فصل بيئة الاختبار عن الإنتاج.

معايير قبول التكامل وتوثيقه

اكتب معايير القبول في خطة الاختبار قبل التنفيذ، ووقّعها مالكا النظامين. المعيار الذي يُكتب بعد رؤية النتائج يتحول إلى تفاوض.

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

1. خطة الاختبار بحالاتها ومعاييرها موقعة قبل التنفيذ.
2. لكل حالة: تاريخ التنفيذ، والمنفذ، ومعرّف العملية في سجل الربط، ولقطات من النظامين، والنتيجة.
3. سجل الملاحظات ومعالجة كل منها وإعادة اختبارها.
4. تقرير مطابقة لدفعات الحجم.
5. محضر قبول التكامل موقع من مالك الأرشيف ومالك النظام الآخر.
6. دليل التشغيل: كيف تُقرأ لوحة المتابعة، وكيف تُعاد عملية فاشلة، ومن يُتصل به في كل طرف.

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

أخطاء شائعة في اختبار التكاملات

• الاختبار بحساب مسؤول النظام: تنجح كل الحالات، ثم تفشل في الإنتاج لأن حساب التكامل الفعلي محدود الصلاحيات، أو أسوأ: يُعتمد الحساب الواسع في الإنتاج لأنه «اختُبر».
• التحقق من طرف واحد: الوثيقة وصلت إلى الأرشيف، لكن الرابط لم يعد إلى النظام المالي، أو عاد لكنه يفتح وثيقة أخرى.
• تجاهل التكرار: إعادة المحاولة التلقائية أو اليدوية تُنتج نسختين، ولا يُكتشف ذلك إلا في التقارير.
• بيانات اختبار نظيفة أكثر من الواقع: كل الفواتير كاملة، وكل الموردين موجودون. الواقع فيه حقول فارغة وأسماء بصيغ مختلفة ومرفقات تالفة.
• اختبار التكامل مرة واحدة: تحديث أحد النظامين بعد الإطلاق قد يكسر الربط. أبقِ مجموعة مختصرة من الحالات تُعاد بعد كل تحديث لأي من النظامين.
• ترك قرار السلوك عند الخطأ للمطور: هل تُرفض الفاتورة بلا أمر شراء أم تُعلق؟ هذا قرار عمل يعود لمالك الإجراء، ويُكتب في المواصفة قبل البناء.

الخطوة التالية: خطة اختبار لكل تكامل قبل بنائه

لا تنتظر مرحلة الاختبار لتكتب الحالات. اكتب مسودتها مع مواصفة التكامل، فكثير من الحالات يكشف قرارات لم تُتخذ بعد: ماذا نفعل بفاتورة بلا أمر شراء؟ من يتلقى التنبيه؟ ما حجم الذروة؟ وحدد لكل تكامل ما يلزمك من مورد النظام الآخر من توثيق وبيئة وأشخاص، لأن هذا ما يؤخر الاختبار عادة. وتعرض صفحة أمن التكامل الضوابط التي تتحقق منها الحالات 11 إلى 14، وتوضح صفحة مراحل التنفيذ موقع بناء التكاملات واختبارها في المشروع.

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

أسئلة شائعة