يوضح العرض التجريبي ما يستطيع البرنامج فعله في ظروف مختارة، بينما يفحص اختبار قبول المستخدم (User Acceptance Testing – UAT) ملاءمة النظام المهيأ لعمل المؤسسة الفعلي. وفي برامج الموارد البشرية، يعني ذلك اختبار مسارات الموظفين والصلاحيات والبيانات معًا قبل اعتماد التشغيل أو قبول تغيير كبير، بحيث يستند القرار إلى أدلة لا إلى الانطباع عن واجهة البرنامج.
حوّل المتطلب إلى نتيجة قابلة للفحص
المتطلب (Requirement) يصف ما تحتاج المؤسسة إلى أن يفعله النظام. ومعيار القبول (Acceptance Criterion) شرط محدد للحكم على تحقق هذا الاحتياج. أما حالة الاختبار (Test Case) فتحدد بيانات البداية والخطوات والنتيجة المتوقعة لفحص ذلك الشرط عمليًا.
استبدل عبارة «يدير النظام الإجازات» بحالة محددة: يقدم الموظف طلبًا، ويراجعه المدير المختص، ويتغير الرصيد بصورة صحيحة، ولا يظهر السجل إلا للأدوار المصرح لها. حدد بيانات البداية والإجراء والنتيجة المتوقعة حتى يسهل حسم اختلاف الآراء حول الجاهزية.
تربط إرشادات Microsoft لتخطيط اختبارات تطبيق Dynamics 365 حالات الاختبار بالعمل الذي ينفذه المستخدم. تطبق الأمثلة هنا هذا المبدأ العام على الموارد البشرية، ولا توصي بمورد معين. أعط الأولوية لما يؤثر في الأجور أو الوصول أو سجلات الموظفين أو التقارير الأساسية.
مثال افتراضي: اختبار طلب إجازة
قبل التنفيذ، جهّز بيئة اختبار منفصلة عن التشغيل الفعلي، بإعدادات تمثل النطاق المراد قبوله. درّب المشاركين على الخطوات، وحدد مسؤول تنفيذ كل حالة ومراجع نتيجتها. استخدم حسابات تجريبية للموظف والمدير المختص ومدير غير مختص، دون إرسال إشعارات إلى موظفين حقيقيين.
| العنصر | مثال افتراضي للتوضيح |
|---|---|
| البداية | رصيد الموظف التجريبي 10 أيام |
| الإجراء | يدخل الموظف طلب يومين، ثم يعتمده المدير المختص من حسابه |
| النتيجة | يصبح الرصيد 8 أيام بعد الاعتماد، وتظهر حالة الطلب «معتمد» |
| الصلاحية | لا يعتمد مدير غير مختص الطلب ولا يرى التفاصيل المقيدة |
| تسجيل التنفيذ | النتيجة الفعلية، وحالة النجاح أو الفشل، وتاريخ التنفيذ واسم المنفذ والمراجع |
| الدليل | رقم الحالة وإصدار النظام، ورابط سجل أو لقطة شاشة لا يطلع عليها إلا المصرح لهم |
يفترض المثال خصم يومي عمل كاملين عند الاعتماد، دون عطلات أو إضافة استحقاق جديد أو تعديل متزامن. لذلك يكون الرصيد المتوقع 10 − 2 = 8 أيام. سجّل الرصيد الذي ظهر فعلًا؛ فالنتيجة المتوقعة وحدها ليست دليل نجاح. اختبر سياسة المؤسسة الفعلية، بما فيها الإلغاء وأجزاء اليوم وقواعد التقويم المنطبقة. نجاح الحالة البسيطة لا يثبت صحة جميع الاختلافات.
اربط المتطلبات بحالات الاختبار
بعد إعداد المثال الأول، أنشئ مصفوفة تتبع المتطلبات (Requirements Traceability Matrix). وهي جدول يربط رقم كل متطلب بحالات اختباره ونتائجها وأدلتها، لكشف المتطلبات التي لم تُفحص. قد يحتاج المتطلب الواحد إلى اختبار المسار العادي والاستثناء والصلاحية. ميز الحالات الناجحة والفاشلة وغير المنفذة والمتوقفة بسبب عائق. الحالة التي لم تُنفذ ليست ناجحة، حتى لو كان المورد يتوقع أنها ستعمل بعد تحديث لاحق.
في مثال الإجازة، لا تكتف بتغير الرصيد من 10 إلى 8 أيام. اختبر رفض الطلب وإلغاءه وفق السياسة المهيأة، وتحقق من أثر ذلك في الرصيد والتقارير والإشعارات. استخدم حسابات بأدوار مختلفة لتأكيد من يستطيع الإجراء. الأرقام هنا توضيحية؛ لا تحدد استحقاقًا قانونيًا ولا سياسة ملزمة لأي مؤسسة.
حدد لكل حالة إصدار النظام والإعدادات وبيانات البداية. إذا غير الفريق قاعدة حساب أثناء الاختبار، فقد لا تعود النتائج السابقة صالحة لذلك الجزء. سجل ما تأثر وأعد اختباره. يمنع هذا الربط اعتماد نتائج مأخوذة من إعدادات مختلفة كما لو أنها تثبت جاهزية نسخة واحدة.
اختبر المسار بين الفرق والأنظمة
تتبع الانضمام وتغيير الوظيفة والإجازة ومغادرة المؤسسة. افحص انتقال البيانات إلى الرواتب وإدارة الحسابات والتقارير. فقد تكون الشاشة صحيحة، بينما ترسل معلومات خاطئة إلى نظام آخر. التكامل (Integration) هو تبادل البيانات أو الإجراءات بين نظامين. تحقق من النتيجة النهائية عند كل تكامل مؤثر.
أدرج الاستثناءات: غياب المدير أو رفض الطلب أو انتقال الموظف أثناء الإجراء أو تعطل التكامل. حدد من يستقبل المشكلة وكيف يستمر العمل. يجب أن يشارك المستخدمون الفعليون، مع دعم المختصين التقنيين عند الحاجة.
طابق البيانات المنقولة
قارن المجاميع المهمة وعينات السجلات بين المصدر المعتمد والنظام الجديد. لا يكفي تطابق عدد الموظفين؛ فقد يُحذف سجل وتُكرر نسخة من سجل آخر، فيبقى العدد نفسه. افحص المعرفات وتواريخ السريان والأرصدة والعلاقات المؤثرة. ووثق التحويلات المتوقعة بدل اعتبار كل اختلاف خطأ.
استخدم بيانات اصطناعية (Synthetic Data)، أي سجلات تجريبية لا تخص أشخاصًا حقيقيين، أو بيانات حقيقية محمية بضوابط معتمدة. وإذا لزمت بيانات شخصية، فاعتمد الوصول وقلل الحقول وطبق قواعد الاحتفاظ. لا تضع صور سجلات سرية في أداة عيوب مفتوحة. ينبغي أن يثبت الدليل النتيجة دون إنشاء مخزن بيانات غير مضبوط.
اختبر الممنوع إلى جانب المسموح
يجب أن يتضمن اختبار الصلاحيات إجراءً مرفوضًا وآخر مسموحًا. تحقق من عدم وصول الموظف إلى سجلات غيره المقيدة، ومن حدود رؤية المدير وصلاحيات المشرف. اختبر التصدير والتقارير، لا الشاشات الرئيسية وحدها.
افحص سحب الوصول عند تغير الدور أو المغادرة، وكيفية اعتماد الصلاحية الاستثنائية وإنهائها. اطلب من المسؤولين التقنيين فحص الضوابط التي تتجاوز ملاحظة مستخدم الأعمال؛ فاختبار القبول لا يحل محل التقييم الأمني المتخصص.
اجعل العيب قابلًا للمعالجة
سجل المتوقع والفعلي وأثر الخطأ وخطوات تكراره والمسؤول عنه. شدة العيب (Severity) تصف حجم أثره، بينما أولوية الإصلاح (Priority) تحدد ترتيب معالجته ودرجة استعجاله. فالخلل الشكلي وحساب الأجر الخاطئ لا يحملان الأثر نفسه. اتفق على العيوب المانعة للتشغيل وصاحب صلاحية قبول مشكلة متبقية موثقة.
بعد الإصلاح، أعد تنفيذ الحالة الفاشلة للتحقق من زوال العيب. ثم نفّذ اختبارات الانحدار (Regression Testing) على الحالات المرتبطة، للتأكد من أن الإصلاح لم يعطل وظائف كانت تعمل. اربط النتيجة بالإعداد والإصدار المختبرين. لا يعادل قول المورد إنه أصلح المشكلة تحققًا فعليًا من القبول.
اعرض الأدلة في اجتماع القبول
قدم ملخصًا يبين المتطلبات المختبرة والعيوب المفتوحة وأثرها في العمل. لا تعرض نسبة نجاح عامة وحدها؛ فقد تفشل حالة واحدة تخص الأجور بينما تنجح حالات كثيرة أقل أثرًا. افصل شدة العيب عن أولوية إصلاحه، ووضح من يعتمد الحل المؤقت ومتى ينتهي العمل به.
اختبر الحل المؤقت (Workaround) أيضًا، وهو إجراء يتيح استمرار العمل إلى حين إصلاح العيب. إذا اقترح الفريق تصحيح رصيد يدويًا، فحدد من يملك الصلاحية، وكيف يراجع التعديل، وكيف يمنع تكراره عند عودة التكامل. لا تعتمد إجراءً يدويًا غامضًا باعتباره معالجة كاملة. ينبغي أن يفهم مسؤول الأعمال عبء الحل وخطر الخطأ قبل قبوله.
ناقش ما سيحدث بعد التشغيل: جهة استقبال البلاغات، وطريقة الوصول إلى السجلات، ومسؤول التصعيد، وكيفية معالجة عطل يمنع العمل. اطلب دليلًا على تجربة خطة الرجوع (Rollback Plan)، أي استعادة الوضع السابق إذا تعذر استمرار الإطلاق. يجب أن توضح الخطة أيضًا مصير المعاملات التي أُدخلت بعد بدء التشغيل. وجود نسخة احتياطية وحده لا يثبت قدرة الفريق على استعادة الخدمة والبيانات بصورة صحيحة.
يسجل قرار القبول النطاق والإصدار المقبولين والاستثناءات المعتمدة وأصحابها. إذا أُطلق قسم أو مسار محدود أولًا، فبيّن ما لم يشمله القرار. ثم راجع النتائج بعد الاستخدام الفعلي، لأن الاختبار المنظم يقلل الغموض لكنه لا يضمن غياب جميع العيوب في كل ظروف التشغيل.
اجعل القبول قرارًا مسؤولًا
قبل الاعتماد، تحقق من الاختبارات الحرجة ومطابقة البيانات وتدريب المستخدمين ومسؤولية الدعم وخطة بديلة قابلة للتنفيذ. سجل المسائل المفتوحة والقرارات بوضوح. إذا لم تكف الجاهزية، فقلص نطاق الإطلاق أو أجله بدل إخفاء العيوب خلف نسبة إنجاز.
تساعد خدمة نمذجة الأعمال والعمليات لدى أتماكس على تحويل إجراءات الموارد البشرية إلى متطلبات وحالات قبول. ابدأ بمسار موظف مهم واختبره كاملًا مع استثناء واقعي واحد.