لماذا يفشل اختبار قبول المستخدم (UAT) حتى عندما يبدو ناجحًا
في العديد من دورات اختبار قبول المستخدم (UAT)، تُصنّف جميع السيناريوهات على أنها ناجحة، وبعد أسبوعين من إطلاق النظام، تُفتح عشرات الطلبات. هذه ليست مفارقة؛ بل هي نتيجة مباشرة لاختبار تم تصميمه حول الشاشات.
الاختبار الذي يتمحور حول الشاشة يسأل: "هل يمكن إنشاء سجل؟" أما الاختبار الذي يتمحور حول العملية فيسأل: "هل يمكن لممثل خدمة العملاء استلام طلب، وتحديد ما إذا كان العميل موجودًا تحت اسم آخر، والتحقق من أهليته في النظام الأساسي، وفتح حالة، وتحويلها إلى جهة أخرى، وإغلاقها – مع وجود العميل مرتين في النظام؟" السيناريو الثاني يكشف ما يغفل عنه الأول.
يقدم هذا الدليل هيكل اختبار قبول المستخدم (UAT) الذي يركز على السؤال الثاني. الارتباط بالمراحل الأخرى للمشروع موجود في دليل تنفيذ Salesforce.
ما يجب أن يكون جاهزًا قبل البدء
- بيئة مستقرة لا تتلقى عمليات نشر في منتصف الدورة، باستثناء إصلاحات حاسمة ومُعتمدة.
- بيانات اختبار بحجم وتعقيد مماثلين لبيئة الإنتاج.
- مستخدمون بصلاحيات حقيقية — وليس صلاحيات مسؤول (Admin) للجميع. نصف مشاكل الصلاحيات تُكتشف فقط عندما يكون المختبر يمتلك الملف التعريفي الصحيح.
- معايير قبول مُحددة لكل عملية أساسية.
- آلية إبلاغ موحدة عن الأخطاء، بحد أدنى من الحقول الإلزامية.
العنصر الأكثر تعرضًا للتجاهل هو الثالث، وهو الذي يسبب أكثر المشاكل إحراجًا في يوم الإطلاق.
كيفية بناء سيناريو يكشف المشاكل
السيناريو الجيد يبدأ بشخصية وحالة بداية، وليس بنقرة. هيكل فعّال:
- من؟ — الدور والصلاحية الدقيقة.
- حالة البداية — أي معلومات موجودة في النظام قبل بدء السيناريو.
- ماذا يحدث؟ — الحدث التجاري الذي يُشغّل العملية.
- ماذا يفعل المختبر؟ — على مستوى الإجراء التجاري، وليس على مستوى النقرة.
- النتيجة المتوقعة — بما في ذلك ما حدث في أنظمة أخرى.
- ما لا ينبغي أن يحدث؟ — السجل لا يُكشف لمن لا يجب أن يراه، الإشعار لا يُرسل مرتين.
القسم السادس هو ما يميز بين قائمة التحقق والاختبار الاحترافي.
ست مجموعات من السيناريوهات يجب تضمينها
| المجموعة | مثال لسيناريو | ما تكشفه |
|---|---|---|
| المسار الطبيعي | عملية كاملة من البداية إلى النهاية | إمكانية تنفيذ العملية من الأساس |
| الاستثناء التجاري | الإلغاء، الائتمان، العودة إلى مرحلة سابقة | منطق بُني في اتجاه واحد فقط |
| البيانات الإشكالية | عميل مكرر، اسم بالعربية والإنجليزية، حقل فارغ | عدم كفاية التعيين والتنظيف |
| الصلاحيات | مستخدم يحاول الوصول إلى سجل لوحدة أخرى | ثغرات في نموذج الكشف |
| فشل التكامل | النظام الهدف غير متوفر | معالجة الأخطاء، الحلقات، التكرار |
| الحجم | إجراء جماعي على عدد كبير من السجلات | قيود الأداء والأتمتة |
إن غياب مجموعة كاملة من القائمة هو علامة على أن الاختبار سيعطي شعورًا زائفًا بالأمان.
تصنيف الخطورة — شرط إدارة الدورة
بدون تصنيف متفق عليه، تبدو كل مشكلة عاجلة، ويصبح قرار الإطلاق محل جدل. نموذج من أربع مستويات يكفي:
| المستوى | التعريف | التأثير على الإطلاق |
|---|---|---|
| حاسم | لا يمكن إكمال عملية أساسية، لا يوجد حل بديل | حاسم |
| خطير | العملية ممكنة بحل بديل معقد أو حفظ بيانات خاطئة | حاسم ما لم يتم الموافقة عليه صراحة |
| متوسط | إزعاج كبير، حل بديل معقول | ليس حاسمًا، يدرج في خطة الإصلاح |
| منخفض | صياغة، ترتيب الحقول، تحسين | يجمع للموجة التالية |
القاعدة المهمة: يحدد مالك العملية التصنيف بالاشتراك مع الفريق التقني، وليس من أبلغ عن المشكلة.
شروط الانتقال إلى الإنتاج
تُصاغ هذه الشروط قبل بدء الدورة وليس في نهايتها:
- صفر مشكلات حرجة مفتوحة.
- جميع المشكلات الخطيرة تم إغلاقها أو الموافقة عليها كتابيًا مع حل بديل ووقت إصلاح.
- جميع العمليات الأساسية تم تشغيلها في الدورة الثانية بدون فشل جديد.
- أصحاب العمليات وافقوا كتابيًا.
- توجد خطة للعودة إلى الإصدار السابق (rollback plan) تم اختبارها، وليس فقط كتابتها.
مثال توضيحي: صندوق التقاعد
السيناريو افتراضي ويهدف للتوضيح. قام صندوق تقاعد باختبار عملية معالجة طلبات الأعضاء. الدورة الأولى لاختبار قبول المستخدم (UAT) مرت بالكامل تقريبًا. لاحظ الفريق أن جميع المختبرين استخدموا ملفًا تعريفيًا موسعًا واحدًا، لأن تخصيص الملفات التعريفية الدقيقة قد تأخر.
في الدورة الثانية، مع الملفات التعريفية الحقيقية، تم العثور على إحدى عشرة مشكلة: لم يتمكن الممثلون من رؤية سجلات الأعضاء الذين تم نقلهم بين المسارات، وظهر زر الموافقة على الاستثناء لمن ليس لديهم صلاحية، وأعاد تقرير أعباء العمل نتائج جزئية لمديري الفرق. لم تكن أي من هذه المشاكل تتعلق بالوظائف التي تم اختبارها في الدورة الأولى – كانت جميعها في نموذج الكشف.
النتيجة العملية التي تم تبنيها هناك: لا يتم بدء دورة اختبار قبول المستخدم (UAT) قبل أن يتم تعيين جميع المشاركين على الملف التعريفي الذي سيعملون به في بيئة الإنتاج.
أخطاء إدارية تزيد من تكلفة الدورة
- نشر الإصدارات في منتصف الدورة، مما يبطل صحة الاختبارات التي تم إجراؤها بالفعل.
- إبلاغ المختبرين عبر WhatsApp والبريد الإلكتروني بالتوازي مع نظام التتبع.
- سيناريوهات مكتوبة على مستوى النقرة، مما يحول أي تغيير في الواجهة إلى تحديث للوثائق.
- تقصير الدورة الثانية بسبب ضغط الجدول الزمني — وهي الدورة التي تكشف عن الانحدارات.
تظهر هذه الأنماط إلى جانب إخفاقات أخرى في دليل الأخطاء الشائعة في تنفيذ CRM، ومسؤولية كل منها محددة في دليل أدوار فريق مشروع Salesforce.
عند استبدال نظام قائم
في مشروع الاستبدال، يضيف اختبار قبول المستخدم (UAT) دورًا ثانيًا: المقارنة. تُشغل نفس السيناريوهات العشرة في كلا النظامين، وتُقارن النتائج حقلًا بحقل. هذه هي الأداة الأكثر فعالية لاكتشاف فجوات التعيين قبل أن تتحول إلى فجوات في مصداقية النظام. تفاصيل تسلسل الإجراءات في مثل هذا الانتقال موجودة في دليل استبدال CRM بـ Salesforce.
ما تبقى بعد الدورة
سيناريوهات اختبار قبول المستخدم (UAT) ليست وثيقة لمرة واحدة. إنها الأساس لاختبارات الانحدار في كل إصدار مستقبلي، وهي أفضل مصدر لمواد التدريب — لأنها مكتوبة بلغة العملية وليس بلغة النظام. إن الاحتفاظ بها بتنسيق يمكن تشغيله مرة أخرى هو أرخص استثمار يمكن القيام به للعام القادم.