Dynamics 365 UAT: دليل عملي

متى تحتاج إلى UAT في Dynamics 365

يجيب اختبار قبول المستخدم عن سؤال واحد: هل تستطيع الأعمال أداء عملها في هذا الإصدار من Dynamics 365؟ يختبره الأشخاص الذين يؤدون العمل، بكلماتهم الخاصة، قبل أن يصل إلى بيئة الإنتاج. وتحتاج إليه في هذه اللحظات.

• الإطلاق. أول Dynamics 365 Sales أو Customer Service، أو الانتقال من نظام CRM آخر.
• تطبيق أو وحدة جديدة. Customer Service إلى جانب Sales، أو تطبيق جديد يستند إلى نموذج (model-driven app) لفريق، أو بوابة للعملاء، أو ميزات Copilot تقوم بتشغيلها.
• تغيير كبير. تكامل جديد مع نظام ERP، أو طريقة جديدة لتوجيه الحالات.
• التحديثات من Microsoft. لم تعد Microsoft تجمع تغييرات Dynamics 365 في موجتَي إصدار في السنة. تُطرح الميزات الجديدة والتغييرات على مدار العام. أُرشفت خطط الإصدار في أكتوبر 2026؛ وما هو قادم موجود الآن في خارطة طريق Microsoft على aka.ms/AIatWorkRoadmap. يمكن لأي تحديث أن يغيّر طريقة عمل نظامك، حتى لو لم تغيّر أنت شيئًا.

يحتاج الإطلاق إلى UAT كامل. أما التحديثات فتحتاج إلى اختبار انحدار أقصر للعمليات الأهم، بإيقاع ثابت. المزيد عن ذلك في بعد الإطلاق.

البيئات

لا تختبر أبدًا في بيئة الإنتاج. في مركز إدارة Power Platform، لكل بيئة نوع. ولـ UAT تحتاج إلى بيئة sandbox.

نسخة من بيئة الإنتاج

أقرب ما تصل إليه من الواقع هو نسخة من بيئة الإنتاج في بيئة sandbox. عندما تنسخ بيئة، تختار ما يُنقل معها:

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

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

الحلول والـ build

تصل تغييرات المشروع إلى بيئة UAT على شكل حلول. استوردها كحلول مُدارة، عبر مسار (pipeline) إن كان لديك واحد، لكي تحصل بيئة UAT على ما ستحصل عليه بيئة الإنتاج لاحقًا بالضبط.

• اتفق على موعد استيراد الحلول بينما يستمر الاختبار، مثلًا مرة واحدة في اليوم بعد الفرز. فالاستيراد في منتصف اختبار قد يغيّر الشاشة أمام المختبِر.
• دوِّن الحلول وإصداراتها الموجودة في بيئة UAT. رقم إصدار الحل هو الـ build الذي تختبره، وكل مشكلة وكل إعادة اختبار تنتمي إلى build واحد.

بيانات الاختبار

يخسر المختبِرون ساعات عندما لا تكون البيانات جاهزة. جهّزها قبل يوم الاختبار الأول:

• الحسابات وجهات الاتصال لكل نوع من العملاء تختبره، مع المالك ووحدة الأعمال الصحيحين.
• المنتجات وقوائم الأسعار. يحتاج المنتج إلى عنصر في قائمة الأسعار قبل أن يمكن إضافته بالسعر الصحيح، ويجب نشره قبل أن يتمكن مندوبو المبيعات من استخدامه. تحقّق من وجود قائمة الأسعار الخاصة بكل فريق مبيعات.
• قوائم الانتظار واتفاقيات SLA ومقالات المعارف لـ Customer Service: قوائم الانتظار التي تُوجَّه إليها الحالات، واتفاقيات SLA النشطة، ومقالات منشورة للعثور عليها.
• سجلات مفتوحة للعمل عليها: عملاء متوقعون، وفرص في مراحل مختلفة، وحالات مفتوحة.
• لا بيانات شخصية حقيقية حيثما أمكنك تجنّبها. تحتوي النسخة مع كل شيء على جميعها، لذا موّه ما لا يحتاج المختبِرون إلى رؤيته أو اجعله مجهول الهوية.

أدوار الأمان ووحدات الأعمال والمستخدمون لكل دور

يثبت UAT أن كل دور يستطيع أداء عمله، وعمله فقط. وفي Dynamics 365 يعتمد ذلك على أدوار الأمان ووحدة الأعمال والفرق الخاصة بالمستخدم. وتُشارك التطبيقات أيضًا عبر أدوار الأمان: فبدون الدور الصحيح، لا يرى المستخدم التطبيق أصلًا.

• اذكر الأدوار التي تختبرها، مثل مندوب المبيعات ومدير المبيعات ووكيل الخدمة ومشرف الخدمة، مع وحدة الأعمال الخاصة بكل منها.
• امنح كل مختبِر مستخدمًا بهذا الدور تحديدًا في بيئة UAT. يحتاج كل مستخدم إلى ترخيص، في بيئة sandbox أيضًا.
• عندما يختبر شخص واحد عدة أدوار، استخدم مستخدم اختبار منفصلًا لكل دور، أو غيّر الدور بين الاختبارات ودوِّن الدور الذي استُخدم.
• لا تختبر أبدًا بدور مسؤول النظام (System Administrator). فهو يرى كل شيء ويُسمح له بفعل كل شيء، لذا يخفي بالضبط المشكلات التي يجب أن يكشفها UAT.

ما يجب إخبار المختبِرين به عن البيئة

• عنوان بيئة UAT. فالإشارة المرجعية المعتادة تفتح بيئة الإنتاج.
• أي تطبيق يفتحون، مثل Sales Hub أو Customer Service workspace، وبأي حساب يسجّلون الدخول.
• أن البيانات بيانات اختبار: لا شيء مما يفعلونه يصل إلى عميل حقيقي، ولا شيء مما يرونه حديث.
• بمن يتصلون عندما لا يتمكنون من تسجيل الدخول أو لا يرون التطبيق.

في UAT Studioيحصل كل مختبِر على Test role، مثل دور الأمان، وTest account، يظهران أعلى اختباراته بصيغة Log in as …. وتتضمن Notes for testers عنوان البيئة وصناديق بريد الاختبار وبمن يتصلون. ويسجّل المختبِرون الدخول إلى UAT Studio برمز يصلهم عبر البريد الإلكتروني، أو باستخدام Sign in with Microsoft.

حالات اختبار من قصص المستخدمين والعمليات

ابدأ من عمليات الأعمال، لا من الجداول في Dataverse. تغطي عمليتان معظم Dynamics 365 UAT:

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

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

تدفقات عملية الأعمال

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

• كل مرحلة، وما يحدث عندما تكون خطوة مطلوبة فارغة.
• كل فرع، وكل دور: يمكن تشغيل التدفق لبعض أدوار الأمان فقط.

التوجيه واتفاقيات SLA والمعارف

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

خطوات يفهمها مختبِرو الأعمال

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

الأولوية والمخاطر

ليست كل حالات الاختبار بالأهمية نفسها. ضع على كل واحدة علامة Must أو Should أو Could: Must هو ما يجب أن يعمل منذ اليوم الأول، مثل إعداد عرض أسعار أو توجيه حالة. وأضف المخاطرة: ما الذي يكلّفه حدوث خطأ في ذلك بعد الإطلاق. يبدأ المختبِرون بـ Must والمخاطر العالية، فتُنجز الاختبارات المهمة حتى عندما ينفد الوقت.

أضف المسارات غير السعيدة (unhappy paths) أيضًا: حقل مطلوب متروك فارغًا، وخصم يتجاوز الحد، ومستخدم في وحدة أعمال أخرى يجب ألا يرى سجلًا.

في UAT Studioاستورد حالات الاختبار من Excel مع العمودين Priority وRisk، أو اقرأها من Azure DevOps Test Plans، أو ابدأ من سيناريوهات Dynamics 365 في مكتبة القوالب، وهي إضافة لكل باقة مدفوعة. ومع AI test design، يقترح الذكاء الاصطناعي حالات اختبار انطلاقًا من قصص المستخدمين لديك في Azure DevOps، وأيضًا على النموذج الخاص بشركتك، مثل Microsoft Foundry / Azure OpenAI. ولا يصبح أي شيء حالة اختبار حتى توافق عليه.

المختبِرون

اختر أشخاصًا يؤدون العمل كل يوم: مديري الحسابات ووكلاء الخدمة ومديريهم للموافقات وقوائم الانتظار ولوحات المعلومات. اختر مختبِرين من كل فريق وبلد يستخدم Dynamics 365، لأن عملياتهم ووحدات الأعمال وقوائم الأسعار الخاصة بهم تختلف.

كم من الوقت

اتفق على الوقت المخصّص لكل مختبِر مع مديره، واحتفظ بوقت لإعادة الاختبار. فالمختبِرون الذين لا يزالون يتلقّون المكالمات أو يزورون العملاء لن ينتهوا.

اجتماع انطلاق (kick-off)

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

يوم اختبار واحد أم أسبوع

يمنح يوم اختبار واحد تركيزًا وإجابات سريعة، ويناسب نطاقًا صغيرًا. أما أسبوع مقسّم إلى فترات من بضع ساعات فيترك مجالًا لـ builds جديدة ولإعادة الاختبار، ويناسب إطلاقًا يضم عمليات كثيرة. في كلتا الحالتين، حدّد وقتًا للفرز كل يوم.

أثناء UAT

تسجيل المشكلات

المشكلة الجيدة يمكن إصلاحها دون اجتماع. اطلب من المختبِرين:

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

في UAT Studioتعرض إضافة المتصفح لـ Chrome وEdge الاختبارات في لوحة جانبية بجانب Dynamics 365. وتأخذ الخطوة الفاشلة معها لقطة الشاشة ورابط السجل ورسائل الخطأ في الصفحة. ويظهر دور المختبِر بجانب اسمه في المشكلة.

الفرز

راجع المشكلات الجديدة كل يوم، مع الأعمال وفريق Dynamics 365 معًا. أعطِ كل واحدة درجة خطورة وشخصًا يصلحها، وقرّر:

• Fix: مشكلة حقيقية، تُصلح في هذا الإصدار.
• Reject: يعمل Dynamics 365 كما صُمّم، أو كان الاختبار خاطئًا.
• Change request: رغبة، لا خلل. تذهب إلى قائمة الأعمال المتراكمة (backlog)، لا إلى هذا الإصدار.

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

إعادة الاختبار

عندما يصبح الإصلاح ضمن build جديد في بيئة UAT، يختبر المختبِر الذي اكتشف المشكلة الخطوة مرة أخرى. دوِّن على أي build أُجريت كل إعادة اختبار. وبعد إصلاح كبير، اختبر العمليات المحيطة به مرة أخرى أيضًا.

الحالة اليومية

أرسل إلى اللجنة التوجيهية تقريرًا موجزًا بالحالة كل يوم: التقدّم مقارنة بالخطة، والمشكلات المفتوحة حسب الخطورة، وما يعيق العمل. لا مفاجآت في اجتماع go/no-go.

في UAT Studioيجري الفرز على شاشة مشتركة مع Fix وReject وChange request. تتحوّل المشكلة إلى عنصر عمل Bug في Azure DevOps؛ وعند إنجازه هناك، تصبح المشكلة Ready for retest ويتلقى المختبِر بريدًا إلكترونيًا. وتحتفظ كل جولة بالإصدار والـ build والبيئة الخاصة بها. ويتلقى Microsoft Teams المشكلات الجديدة والجولات والاعتمادات في قناة.

الاعتماد وقرار go/no-go

ينتهي UAT بقرار من الأعمال. اتفق على معايير الخروج قبل يوم الاختبار الأول، حتى لا يتجادل أحد بشأنها في النهاية:

• لا توجد أي مشكلة Critical مفتوحة.
• نجحت كل حالة اختبار Must.
• لكل مشكلة High مفتوحة حل بديل أو موعد للإصلاح تقبله الأعمال.
• لكل حالة اختبار ضمن النطاق نتيجة.

من يوقّع

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

ما الذي يتضمنه التقرير

• ما كان ضمن النطاق، وما لم يُختبر.
• النتائج لكل عملية أو فريق، ولكل أولوية.
• البيئة والحلول والـ build التي جرى اختبارها.
• المشكلات المفتوحة حسب الخطورة، مع القرار بشأن كل منها.
• عمليات الاعتماد، مع شروطها، والمخاطر المعروفة للأسابيع الأولى.

في UAT Studioاعتماد لكل مجموعة: Accepted أو Accepted with conditions أو Rejected. افتراضيًا، لا يمكن لأحد القبول ما دامت هناك مشكلة Critical مفتوحة. ويكون تقرير go/no-go جاهزًا بصيغة PDF أو كشرائح عند ورود آخر نتيجة.

جولات انحدار بإيقاع ثابت

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

• اختر إيقاعًا، مثلًا جولة انحدار كل شهر أو كل ربع سنة، وضع التواريخ في تقويم المختبِرين الآن.
• قبل كل جولة، اقرأ خارطة طريق Microsoft والرسائل الموجّهة إلى المسؤولين لديك، ودوِّن التغييرات التي تمسّ عملياتك.
• جرّب الميزات التي في مرحلة المعاينة أو الوصول المبكر في بيئة sandbox أولًا، قبل أن تصل إلى المستخدمين لديك.
• اختبر حالات الاختبار Must مرة أخرى، وShould إذا سمح الوقت، مع عدد قليل من المختبِرين من الأعمال.
• سجّل المشكلات كما في UAT، وأصلحها قبل أن يصل التغيير إلى المستخدمين لديك.

في UAT Studioاختر Dynamics 365 كنظام CRM للمشروع. ينسخ Start a regression round حالات الاختبار التي تختارها من UAT سابق، مع خطواتها وبيانات اختبارها ونتائجها المتوقعة: Must and Should أو Only Must أو All test cases in scope.

مجاني الاستخدام

لكل ما يجب ترتيبه قبل UAT وأثناءه وبعده، اطّلع على قائمة تحقق UAT لإطلاق نظام CRM، المتوفرة أيضًا كملف Excel مجاني. ولمعرفة ما يقدّمه UAT Studio لـ Dynamics 365 UAT، اطّلع على Dynamics 365 UAT.

Microsoft وDynamics 365 وPower Platform وAzure DevOps وMicrosoft Teams علامات تجارية لمجموعة شركات Microsoft. ولا يرتبط UAT Studio بـ Microsoft ولا يحظى بتأييدها.