اختبار قبول ERP: الأدوار والموافقات وحدود الوصول

Sawsan Sayad
تغطي Sawsan Sayad أنظمة المؤسسات والذكاء الاصطناعي وبرمجيات الأعمال لدى The Blue LED Global.
اختبر كل موافقة في ERP بالحسابات والصلاحيات التي سيستخدمها الموظفون عند الإطلاق. يجب أن يصل طلب الشراء إلى المعتمد الصحيح، وأن تُمنع الموافقة غير المخولة، وأن تبقى السجلات خارج نطاق المستخدم المتفق عليه غير متاحة له. وثق النتيجة المتوقعة والفعلية لكل حالة، ثم اطلب من مسؤول الأعمال المعني مراجعة الأدلة.
عند إطلاق النظام بالعربية والإنجليزية عبر عدة كيانات، اجعل كل حالة اختبار تجمع مستخدماً محدداً وإجراءً وسجلاً. توضح الأداة التالية هذه التركيبات باستخدام سياسة مشتريات افتراضية. عدّل المتطلبات وفق مؤسستك ومنتج ERP المختار قبل تنفيذ الاختبارات.
ما الذي يجب أن يثبته UAT بشأن الوصول؟
يتحقق اختبار قبول المستخدم، أو UAT، من ملاءمة العملية المنفذة وسهولة استخدامها من وجهة نظر المسؤولين عن تشغيلها. تدعو إرشادات Microsoft لاختبارات Dynamics 365 إلى مشاركة مستخدمي الأعمال في بيئة اختبار متكاملة، وتدريبهم قبل UAT. وتشمل إرشادات اختبار العمليات أيضاً استخدام الأدوار الأمنية المقصودة واختبار الحالات التي يُتوقع رفضها أو فشلها.
حوّل ذلك إلى ثلاثة أسئلة لمسؤول العملية:
- هل يستطيع الموظف المعني إتمام المهمة وتسليم النتيجة الصحيحة إلى الشخص التالي؟
- هل تُعالج الإجراءات المحظورة والسجلات خارج نطاق الوصول وفق السياسة المعتمدة؟
- هل يستطيع فريق الأعمال فهم المعاملة المرفوضة أو المعدلة أو الاستثنائية ومعالجتها؟
يساعد العرض الذي يقدمه الاستشاري على شرح العملية. أما سجل القبول، فينبغي أن يحدد مستخدم الأعمال الذي أجرى الاختبار والحساب الفعلي المستخدم. إذا كان الاستشاري يعمل بصلاحيات مدير النظام، فلا يثبت نجاح معاملته أن موظف المشتريات يستطيع تنفيذ العمل نفسه.
أدرج هذه الأدلة ضمن نطاق تنفيذ ERP المتفق عليه، مع تخصيص وقت لمعالجة العيوب وإعادة الحالات المتأثرة.
حدد قرار الصلاحية قبل كتابة خطوات الاختبار
ابدأ بعبارة أعمال واضحة: من يحق له تنفيذ أي إجراء، وعلى أي سجلات، وتحت أي شروط؟ مثال: «يستطيع مقدم الطلب إرسال طلب شراء لكيانه، ويجب أن يوافق عليه شخص آخر مخول». تأكد أولاً من أن العبارة تمثل متطلباً معتمداً في المؤسسة قبل تحويلها إلى حالة اختبار.
استخدم تعبير «حسب الدور» لتبسيط النقاش مع فرق الأعمال. فقد يعتمد المنتج أيضاً على النطاق التنظيمي أو ملكية السجل أو المجموعات أو العلاقات أو خصائص أخرى لتحديد الوصول. في Dynamics 365 للمالية والعمليات، تصف Microsoft الأدوار والواجبات والامتيازات والصلاحيات، مع إمكانية تقييد الوصول إلى السجلات بسياسات أمن البيانات. تحقق من الضوابط المقابلة في المنتج والإصدار قيد التنفيذ.
وثق لكل سيناريو:
- المتطلب ومسؤول السياسة ورقم إصدارها
- وظيفة المستخدم في العملية وحساب الاختبار وجميع الأدوار أو المجموعات ذات الصلة المسندة إليه
- الكيان والقسم وملكية السجل وأي حدود أخرى للوصول إلى البيانات
- الإجراء وحالة المعاملة والشرط الذي يسمح به أو يمنعه
- النتيجة المتوقعة للعملية وقرار الوصول المتوقع
- بيانات الاختبار والمتطلبات السابقة ومكان الأدلة ومسؤول القبول
افصل قاعدة الأعمال عن اسم الإعداد داخل النظام. فاسم دور مثل «معتمد المالية» لا يوضح وحده نطاق الوصول الفعلي؛ يجب فحص التعيينات واختبارها. راجع مجموعات الأدوار التي يحملها الأشخاص في الواقع، إلى جانب اختبار كل دور منفرداً. وقد يحتاج الموظف الذي يغطي وظيفتين إلى حالات تختلف عن حالات من يتولى وظيفة واحدة فقط.
اختبر الإجراءات المسموحة والحدود والاستثناءات
الجدول التالي مثال تخطيطي أصلي. يفترض سياسة تفصل تقديم الطلب عن الموافقة عليه، وتقيد الوصول بحسب الكيان، وتشترط تجديد الموافقة عند تغييرات جوهرية محددة. هذه متطلبات توضيحية، وليست سلوكاً افتراضياً نَعِد بتوفره في أي منتج ERP.
| السيناريو | الحساب والنطاق | النتيجة المتوقعة | الدليل المطلوب |
|---|---|---|---|
| إرسال طلب مستوفٍ للشروط | مقدم طلب في الكيان أ | وصول الطلب إلى قائمة الموافقات الصحيحة | مرجع الطلب وحالته والقائمة المستلمة |
| الموافقة ضمن حدود التفويض | المعتمد المحدد في الكيان أ | انتقال الطلب إلى المرحلة التالية المسموحة | هوية المعتمد وسجل تغير الحالة |
| محاولة اعتماد الشخص لطلبه | مقدم الطلب على طلبه نفسه | منع الإجراء وفق السياسة المتفق عليها | الرفض وبقاء حالة الموافقة دون تغيير |
| فتح سجل لكيان آخر | مستخدم الكيان أ وسجل تجريبي للكيان ب | استمرار منع الوصول إلى البيانات المقيدة | نتيجة الوصول دون نسخ بيانات حساسة |
| تعديل مبلغ بعد الموافقة | محرر مخول على الطلب المعتمد | إعادة فتح مسار الموافقة المطلوبة أو منع التعديل | الحالة قبل التعديل وبعده ونتيجة التوجيه |
| غياب المعتمد | طلب خلال فترة تفويض متفق عليها | السماح للبديل المخول وحده باتخاذ القرار | تواريخ التفويض وهوية المنفذ وسجل القرار |
لا تعتبر اختبار المنع ناجحاً لمجرد اختفاء زر. توصي إرشادات OWASP للتحكم في الصلاحيات بالمنع افتراضياً والتحقق من الصلاحيات مع كل طلب. اطلب من الفريق التقني التحقق من نقاط الدخول المعنية في التطبيق والتقارير والتصدير والتكامل، ضمن نطاق الاختبار المصرح به. وسجل الاستجابة وما إذا كانت حالة الأعمال قد تغيرت فعلياً.
لا يحل UAT محل الاختبارات الأمنية المتخصصة. حدد من يتولى التحقق الأعمق من الصلاحيات، واربط نتائجه بقرارات القبول عندما تؤثر في العملية.
نفذ سيناريو موافقة واحداً من بدايته إلى نهايته
جهز مثالاً مضبوطاً
مثال افتراضي: تعتمد مؤسسة سياسة اختبار تمر فيها الطلبات حتى 10,000 وحدة من عملة تجريبية مختارة بمستوى موافقة واحد، وتحتاج الطلبات الأعلى إلى مستوى إضافي. لا يستطيع مقدم الطلب اعتماد طلبه، وللكيانين المستخدمين في المثال نطاقا وصول منفصلان.
حدد أساس المبلغ قبل الاختبار: هل هو الصافي أم الإجمالي؟ مبلغ البند أم مجموع المستند؟ وما قواعد التقريب وتحويل العملة إن وجدت؟ استخدم قيماً أقل من الحد مباشرة، ومساوية له، وأعلى منه مباشرة. وإلا فقد يعلن مختبران نتيجتين مختلفتين لأن كلاً منهما يختبر تفسيراً مختلفاً للسياسة.
جهز حسابات اختبار مستقلة ومعتمدة لمقدم الطلب والمعتمد والبديل والمستخدم خارج النطاق. حدد نسخة الإعداد الأساسية وإصدار بيانات الاختبار. استخدم بيئة غير إنتاجية معزولة، وتأكد من أن رسائل الموردين وواجهات الدفع والمخرجات ذات الأثر الفعلي تستخدم وجهات اختبار معتمدة أو أنها معطلة بأمان.
تتبع الطلب عبر كل حالة
أرسل الطلب، وافحص قائمة عمل الشخص التالي، ونفذ الموافقة، ثم تحقق من الحالة الناتجة والمستند الذي يليها. كرر المسار مع الرفض والتصحيح. افحص من يستطيع تعديل السجل في كل مرحلة، وأي تغييرات تستدعي قراراً جديداً بموجب السياسة المعتمدة.
بعد ذلك اختبر الحدود. تحقق من منع اعتماد الشخص لطلبه، ومن وصول الطلب الأكبر إلى مستوى الموافقة الإضافي، ومن عجز المستخدم غير المخول عن تنفيذ الإجراء نفسه. اختبر التفويض داخل الفترة المسموحة وخارجها. إذا كان التفويض غير مدعوم أو يعمل بطريقة لا تحقق المتطلب، فسجل فجوة ملاءمة تحتاج إلى قرار أعمال.
أضف تغييراً رقابياً مقصوداً في بيئة الاختبار، مثل إلغاء إسناد دور إلى حساب اختبار معتمد عبر إجراء الإدارة المصرح به. تحقق من الوصول الناتج، بما في ذلك موعد سريان التغيير وفق قواعد الجلسات في المنتج. أعد الإعداد الأساسي المتفق عليه قبل الدورة التالية، واحتفظ بسجل التغيير.
تحقق من تعارض المهام بصورة مستقلة
يتعلق فصل المهام بمجموعات المسؤوليات التي قررت المؤسسة ضرورة توزيعها على أشخاص مختلفين. يجيب توجيه الموافقات وفحص تعارض المهام عن سؤالين مترابطين لكنهما مختلفان. فقد يُوجّه الطلب بصورة صحيحة بينما يحمل مستخدم مجموعة أدوار غير مناسبة.
هناك تفصيل خاص بالمنتج يستحق الانتباه: توضح تعليمات Microsoft لإعداد فصل المهام أن إنشاء القاعدة لا يتحقق من الأدوار أو التعيينات القائمة، وأن التحقق مطلوب بعد إنشاء القاعدة أو تعديلها. اسأل عن خطوة التحقق المطلوبة في منصتك المختارة، واحتفظ بنتيجتها إلى جانب اختبارات المعاملات. لا تفترض أن حفظ القاعدة يثبت الالتزام بها.
اجعل الاختبار بالعربية والإنجليزية متكافئاً في المعنى التشغيلي
في الإطلاق ثنائي اللغة، حافظ على مرجع سيناريو واحد وتوقع أعمال مشترك بين اللغتين. في السياسة الافتراضية أعلاه، يمكن أن تختبر إحدى الحالات طلباً بقيمة 10,000 وحدة بالضبط في الكيان أ. يجب أن يستخدم التنفيذ بالعربية والإنجليزية أساس المبلغ نفسه والمعتمد المحدد نفسه ومستوى الموافقة المتوقع نفسه. راجع ترجمة أسماء الإجراءات حتى لا تغير القاعدة التي يجري اختبارها.
اطلب من مراجع أعمال مناسب لكل لغة التحقق مما يلي:
- أسماء الإجراءات: هل يستطيع المستخدم التمييز بين الإرسال والموافقة والرفض والإعادة والإلغاء؟
- سياق السجل: هل الكيان والمورد والعملة ومراجع الطلب واضحة؟
- الأرقام والتواريخ: هل تطابق القيمة المعروضة السجل التجريبي وإعدادات اللغة والمنطقة المتفق عليها؟
- الرسائل: هل يوضح رفض الوصول الخطوة المسموحة التالية دون كشف معلومات مقيدة؟
- المخرجات: هل تصلح المستندات والإشعارات والتقارير المطلوبة للاستخدام باللغة والتخطيط المعنيين؟
- التدريب: هل يستطيع الموظف اتباع العملية المعتمدة باستخدام مواد بلغته المعتادة في العمل؟
سجل عيوب اللغة أو العرض من اليمين إلى اليسار بصورة مستقلة عن أخطاء قواعد الأعمال، مع الاحتفاظ بأثرها على العملية. فقد تعطل رسالة موافقة مبتورة مهمة حرجة. أكد اللغات التي يدعمها المنتج فعلياً وأي تخصيص مطلوب؛ فترجمة دليل التدريب لا تثبت دعم التطبيق للغة نفسها.
اربط النتائج بدليل جاهزية الإطلاق في المنطقة عند مراجعة الاعتماديات الأوسع للدول وموجات التنفيذ.
احتفظ بأدلة يمكن الرجوع إليها عند إعادة الاختبار
نادراً ما توضح لقطة الشاشة وحدها الإعدادات وتعيينات الوصول وتسلسل المعاملة الذي أدى إلى النتيجة. احتفظ بسجل موجز لكل تنفيذ: مرجع السيناريو، وإصدار النظام أو الإعداد، ونسخة بيانات الاختبار، والمختبر، والأدوار المسندة، والتوقيت، والنتائج المتوقعة والفعلية، والعيوب المرتبطة. احتفظ بالمعلومات المسموح بها فقط، واستبعد كلمات المرور والرموز السرية والبيانات الشخصية أو التجارية غير الضرورية.
عند فشل حالة، حدد ما إذا كان السبب إعداداً أو شيفرة أو بيانات أو سياسة غير واضحة أو نقصاً في الوصول أو حاجة إلى التدريب. عين مسؤولاً للمشكلة، ووثق طريقة يمكن بها تكرارها. وإذا غيّر التوضيح السلوك المتوقع، فحدّث المتطلب وحالة الاختبار معاً.
بعد الإصلاح، أعد الحالة الفاشلة والحالات الأخرى المتأثرة بالتغيير. مثلاً، ينبغي أن يؤدي توسيع نطاق كيانات المعتمد إلى فحص السجلات التي أصبح الوصول إليها مسموحاً، وتلك التي يجب أن تظل مقيدة. احتفظ بالفشل الأصلي وإعادة الاختبار كسجلّي تنفيذ مستقلين.
يصف دليل OWASP لأتمتة اختبار الصلاحيات مصفوفة تربط الوظائف بالأدوار وبالبيانات عند الحاجة، ويمكن استخدامها في اختبارات تكامل قابلة للتكرار. استخدم الأتمتة لفحوص الصلاحيات المستقرة عندما تدعمها منصتك، مع الحفاظ على مراجعة مسؤول الأعمال لطريقة العمل الفعلية.
ماذا يجب أن يتضمن قرار الإطلاق؟
تدعو إرشادات Microsoft لاستراتيجية الاختبار إلى تحديد النطاق ومعايير البدء والانتهاء والمسؤوليات ومتابعة النتائج، مع مشاركة أصحاب المصلحة من الأعمال في القبول. اتفق على معايير قرار مراجعة الأدوار والموافقات قبل تنفيذ الاختبارات.
استخدم قائمة القبول المقترحة التالية:
- أُنجزت حالات الإجراءات المسموحة والمحظورة وحدود البيانات ذات الصلة لكل عملية حرجة
- تطابق أدوار الإطلاق وقواعد الموافقة الفعلية الإعداد الذي تمت مراجعته، أو توجد تقييمات صريحة لأثر الفروق
- شملت التغطية اختلافات الكيانات واللغات والتفويض المطلوبة
- توضح العيوب المفتوحة أثرها والمسؤول عنها والحل المؤقت إن اعتُمد والقرار المتخذ
- قيّم مسؤول الضوابط المعني فجوات الصلاحيات أو تعارض المهام
- أُعيد اختبار الإصلاحات والحالات المرتبطة المتأثرة
- وثق مسؤول الأعمال القبول أو التأجيل أو القبول باستثناءات محددة
قد تخفي نسبة النجاح الإجمالية المرتفعة فشل ضابط حرج. راجع التغطية بحسب العملية والمخاطر، وأظهر صراحة الحالات المتوقفة أو التي لم تُنفذ. يحتاج كل استثناء إلى صاحب قرار محدد ونطاق واضح وضابط مؤقت معتمد إن وجد وتاريخ للمراجعة. اتبع شروط الإطلاق المتفق عليها في المؤسسة؛ هذه الأداة ليست شهادة امتثال.
اربط نموذج الأدوار بقرار القبول
تربط The Blue LED Global بين جانبين من هذا العمل: تشمل خدمة الحوكمة وضوابط الوصول لدينا تصميم الأدوار وفصل المهام والتحقق من الضوابط، بينما تشمل خدمة الاختبار والتدريب والدعم تنسيق UAT ومتابعة العيوب وإعادة الاختبار وتمكين المستخدمين بالعربية والإنجليزية. ويُتفق على النطاق والمسؤوليات لكل تعاقد.
جهز للمراجعة التخطيطية عملية واحدة ذات أولوية، وسياسة الموافقات الخاصة بها، وتعيينات الأدوار الفعلية، وحدود الكيانات، وسجلات نموذجية. حدد الشخص المخول بحسم أسئلة السياسة والمستخدمين الذين سيختبرون العمل. ينبغي أن يستند قرار القبول إلى العملية والإعداد والأدلة نفسها.
المصادر وتاريخ مراجعتها
الأداة والمثال الافتراضي توصيات تحريرية للتخطيط. تتناول مراجع Microsoft نظام Dynamics 365، وتتناول مراجع OWASP التحكم في صلاحيات التطبيقات. ولا تثبت توفر الميزات أو التراخيص أو الضوابط نفسها في كل منتج ERP.
- Microsoft Learn: أنواع الاختبارات
- Microsoft Learn: الأمن القائم على الأدوار
- Microsoft Learn: إعداد فصل المهام
- Microsoft Learn: اختبار حل Dynamics 365 قبل النشر
- OWASP: إرشادات التحكم في الصلاحيات
- OWASP: أتمتة اختبار الصلاحيات
تاريخ التحقق من المصادر: 8 أكتوبر 2026.
المصادر
- Microsoft Learn: Types of tests
- Microsoft Learn: Role-based security
- Microsoft Learn: Set up segregation of duties
- Microsoft Learn: Test your Dynamics 365 solution before deployment
- OWASP: Authorization Cheat Sheet
- OWASP: Authorization Testing Automation Cheat Sheet
- The Blue LED Global: Enterprise testing, training and post-go-live support
- The Blue LED Global: Enterprise governance, security and compliance controls