كيف تختبر أتمتة مشروعك قبل تشغيلها على بيانات حقيقية ؟

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

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

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

1. اكتب شروط نجاح الأتمتة قبل اختبارها

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

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

دوّن قبل البدء :

• المدخلات المستخدمة ، ومعرّف الحالة التجريبية .
• النتيجة المتوقعة في السجل والإشعار .
• الإجراء الذي يجب منعه ، مثل إنشاء نسخة إضافية .
• الدليل الذي سيُثبت النتيجة ، مثل السجل المستقبِل وسجل التشغيل .

توصي Microsoft باختبار المسارات المهمة وقدرتها على التعامل مع الأعطال ، وتوثيق الإجراءات والنتائج بصيغة مفهومة . نحول هذا المبدأ هنا إلى حالات صغيرة يستطيع صاحب المشروع مراجعتها مع منفذ الأتمتة .

2. جهّز بيئة اختبار لا تؤثر في العمل الحقيقي

أنشئ نسخة تجريبية من المسار ، واربطها بنموذج وسجل وصندوق استقبال مخصصين للاختبار . تسمية النسخة ( تجريبية ) لا تعزلها إذا بقيت متصلة بجدول العملاء أو بعناوين الموظفين الفعلية .

افحص وجهة كل خطوة تكتب بيانات أو ترسل رسالة . استخدم بيانات مصطنعة مثل ( موقع تجريبي أ ) ومعرّفات تبدأ بـTEST ، ولا تنسخ سجلات حساسة لمجرد تسهيل التجربة .

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

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

3. اختبر الحالات التي قد تكشف أخطاء سير العمل

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

أ. الطلب السليم والبيانات الناقصة

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

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

ب. إعادة معالجة الحدث نفسه

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

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

ج. الصلاحية المرفوضة والفشل الجزئي

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

ثم اختبر العكس : نجح إنشاء السجل وفشل الإشعار . يجب أن تتمكن من معرفة الجزأين كلٍّ على حدة . توضح وثائق Power Automate ، على سبيل المثال ، إمكانية تحديد مسارات مختلفة عند نجاح الخطوة أو فشلها أو انتهاء مهلتها ، وتسجيل الأخطاء أو إيقاف المسار . تختلف وسائل تنفيذ ذلك بين المنصات .

4. افحص إعادة المحاولة دون تكرار الطلب

لنفترض أن الطلب التجريبي TEST-017 وصل ، وأن النظام أنشأ سجل الصيانة ، ثم تعطل إرسال الإشعار . إعادة المسار من بدايته دون التحقق من أثر المحاولة الأولى قد تنشئ سجلًا ثانيًا للطلب نفسه .

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

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

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

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

5. إذا كان المسار يستخدم الذكاء الاصطناعي ، اختبر تفسيره أيضًا

قد تضيف لاحقًا خطوة تقرأ وصف العطل وتقترح تصنيفه . هنا يصبح لديك مستويان للفحص : هل نُقلت البيانات ونُفذ الإجراء بصورة صحيحة ؟ وهل التصنيف نفسه تدعمه الرسالة ؟

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

تذكر وثائق Microsoft أن مخرجات النماذج قد تتضمن معلومات مختلقة أو تتأثر بحقن التعليمات ، وتؤكد أهمية الاختبار والإشراف البشري .

يمكنك الاستعانة بالمساعد لتوسيع قائمة الحالات بهذا الأمر :

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

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

6. سجّل النتيجة الفعلية بدل الاكتفاء بالانطباع

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

مثال لصياغة نتيجة افتراضية مفيدة :

الحالة : إعادة معالجة TEST-017 . المتوقع : بقاء سجل واحد . الفعلي المفترض : ظهور سجلين مرتبطين بمعرّف المصدر نفسه . القرار : فشل يمنع التوسع في التشغيل حتى إصلاح منع التكرار وإعادة الفحص .

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

بعد الإصلاح ، أعد الحالة الفاشلة والحالات المرتبطة بها . إذا عدّلت منع التكرار ، فتحقق أيضًا من أن الطلب الجديد المختلف ما زال يُقبَل ؛ فقد يصلح تعديلٌ مشكلةً ويمنع عملًا صحيحًا .

7. قرّر متى تبدأ التشغيل المحدود ومتى تتوقف

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

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

انتبه إلى أن إيقاف التشغيل لا يعكس آثاره السابقة ؛ فقد يبقى سجل أُنشئ أو إشعار أُرسل . لذلك يلزم فحص الطلبات التي كانت قيد المعالجة ومطابقتها قبل استئناف العمل ، حتى لا تضيع بين المسار اليدوي والآلي أو تُنفذ مرتين .

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

8. الخلاصة

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

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

لا تبحث عن اختبار يمنحك طمأنينة شكلية ؛ ابحث عن دليل تستطيع الرجوع إليه ، وقرار واضح بشأن الأخطاء المقبولة مؤقتًا والأخطاء التي تمنع التشغيل .