Salesforce UAT: دليل عملي

متى تحتاج إلى UAT في Salesforce

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

• الإطلاق. أول Sales Cloud أو Service Cloud، أو الانتقال من نظام CRM آخر.
• سحابة جديدة أو تغيير كبير. إضافة Service Cloud إلى جانب Sales Cloud، أو CPQ، أو تكامل جديد مع نظام ERP، أو طريقة جديدة لتوجيه طلبات الخدمة.
• كل إصدار من Salesforce. لدى Salesforce ثلاثة إصدارات في السنة: Spring وSummer وWinter. يأتي إصدار Winter في الخريف ويحمل رقم السنة التالية. ويمكن لكل إصدار أن يغيّر طريقة عمل الـ org لديك، حتى لو لم تغيّر أنت شيئًا.
• معاينة sandbox. تحصل بيئات sandbox الموجودة على مثيل معاينة (preview instance) على الإصدار الجديد قبل بيئة الإنتاج ببضعة أسابيع. وتلك هي نافذتك للاختبار. وقبل كل إصدار، تنشر Salesforce المثيلات المشمولة بالمعاينة وما يجب فعله لإبقاء بيئة sandbox فيها. تحقّق من ذلك في الوقت المناسب، لأن التحديث (refresh) قد يُدخل بيئة sandbox إلى المعاينة أو يُخرجها منها.

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

بيئة sandbox

لا تختبر أبدًا في بيئة الإنتاج. لدى Salesforce أربعة أنواع من sandbox. اثنان منها مناسبان لـ UAT.

خطّط للتحديث (refresh)

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

• حدّث قبل UAT، ولا تحدّث أثناءه أبدًا. تحقّق من الموعد التالي الذي يمكن فيه تحديث بيئة sandbox.
• انشر الإصدار على بيئة sandbox بعد التحديث. فالعمل الذي لم يكن موجودًا إلا في sandbox يختفي.
• نفّذ الخطوات اللازمة بعد التحديث: وجّه التكاملات وnamed credentials إلى أنظمة الاختبار، لا إلى بيئة الإنتاج، وأوقف المهام المجدولة التي يجب ألا تعمل.
• تحقّق من إمكانية تسليم البريد الإلكتروني (email deliverability). لا ترسل بيئة sandbox الجديدة أو المحدَّثة سوى رسائل النظام. وتحتاج ردود web-to-lead والموافقات ورسائل طلبات الخدمة إلى أكثر من ذلك، لكن بيئة Full sandbox تحتوي على عناوين البريد الإلكتروني الحقيقية لجهات الاتصال لديك. استخدم عناوين اختبار قبل أن تفتح ذلك.

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

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

• الحسابات وجهات الاتصال لكل نوع من العملاء تختبره، مع المالك والمنطقة ونوع السجل (record type) الصحيح.
• المنتجات وprice books. يحتاج المنتج إلى سعر في standard price book قبل أن يُدرج في price book آخر. تحقّق من أن price books الخاصة بكل فريق مبيعات نشطة.
• سجلات مفتوحة للعمل عليها: فرص في مراحل مختلفة، وطلبات خدمة مفتوحة، وطلبات خدمة قريبة من milestone إذا كنت تختبر entitlements.
• لا بيانات شخصية حقيقية حيثما أمكنك تجنّبها. تنسخ بيئة Full sandbox كل شيء، لذا موّه ما لا يحتاج المختبِرون إلى رؤيته أو اجعله مجهول الهوية.

المستخدمون لكل profile وpermission set

يثبت UAT أن كل دور يستطيع أداء عمله، وعمله فقط. أنشئ مستخدم اختبار لكل مزيج من profile والدور وpermission sets تختبره، مثل مندوب مبيعات ومدير مبيعات ووكيل خدمة. يحصل كل مختبِر على مستخدمه الخاص، حتى لا يعمل شخصان أبدًا بالمستخدم نفسه في الوقت ذاته.

بعد التحديث، تضيف Salesforce اسم sandbox إلى كل اسم مستخدم، و.invalid إلى عنوان البريد الإلكتروني لكل مستخدم. اضبط البريد الإلكتروني لكل مستخدم اختبار على عنوان يقرؤه المختبِر، وإلا فلن تصل رسائل إعادة تعيين كلمة المرور والموافقات إلى أحد.

تتيح Log in as للمسؤول رؤية Salesforce بعيني مستخدم آخر. وهي طريقة جيدة للنظر في مشكلة يبلّغ عنها مختبِر. أما في الاختبار نفسه، فيستخدم المختبِرون مستخدم الاختبار الخاص بهم: بهذا تعرف أن profile وpermission sets صحيحة.

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

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

في UAT Studioيحصل كل مختبِر على Test role وTest account، يظهران أعلى اختباراته بصيغة Log in as …. وتتضمن Notes for testers عنوان sandbox وصناديق بريد الاختبار وبمن يتصلون.

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

ابدأ من عمليات الأعمال، لا من الكائنات في Salesforce. تغطي عمليتان معظم Salesforce UAT:

• Lead to cash. يصل عميل محتمل (lead) عبر web-to-lead، فيُسنَد ويُحوَّل. تحصل الفرصة على منتجات من price book، ويُعَدّ عرض سعر وتتم الموافقة عليه، وتُكسب الصفقة، وينتقل الطلب أو العقد إلى الفريق أو النظام التالي.
• إدارة طلبات الخدمة (case management). يصل طلب خدمة (case) عبر email-to-case أو البوابة، فيُوجَّه إلى قائمة الانتظار (queue) أو الوكيل المناسب، ويتبع entitlement وmilestones الخاصة به، ويُحلّ بمقالة معرفية، ويُصعَّد عند الحاجة، ثم يُغلق.

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

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

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

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

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

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

في UAT Studioاستورد حالات الاختبار من Excel مع العمودين Priority وRisk، أو ابدأ من سيناريوهات Salesforce في مكتبة القوالب، وهي إضافة لكل باقة مدفوعة. يرى المختبِرون حالات الاختبار Must أولًا.

المختبِرون

اختر أشخاصًا يؤدون العمل كل يوم: مندوبي المبيعات ووكلاء الخدمة ومديريهم للموافقات والتوقعات والتقارير. اختر مختبِرين من كل فريق وبلد يستخدم Salesforce، لأن عملياتهم وprice books الخاصة بهم تختلف.

كم من الوقت

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

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

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

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

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

في كلتا الحالتين، حدّد وقتًا للفرز كل يوم.

أثناء UAT

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

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

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

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

الفرز

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

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

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

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

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

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

في UAT Studioيجري الفرز على شاشة مشتركة مع Fix وReject وChange request. ويرسل Ready for retest بريدًا إلكترونيًا إلى من يعيد الاختبار. وتعرض نظرة عامة يومية عبر البريد الإلكتروني، أو في Microsoft Teams، نتائج اليوم السابق ومشكلاته.

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

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

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

من يوقّع

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

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

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

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

جولة انحدار لكل إصدار من Salesforce

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

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

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

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

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

Salesforce وSales Cloud وService Cloud علامات تجارية لشركة Salesforce, Inc. ولا يرتبط UAT Studio بـ Salesforce ولا يحظى بتأييدها.