قائمة تحقق UAT لإطلاق نظام CRM

قبل UAT

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

النطاق

• اتفق على العمليات وقصص المستخدمين المشمولة في UAT، ودوّن ما ليس مشمولًا.
• عيّن مالكًا من الأعمال لكل عملية: الشخص الذي يعتمدها.
• اتفق على معنى Critical وHigh وMedium وLow قبل تسجيل أول مشكلة.

حالات الاختبار

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

المختبِرون

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

البيئة وبيانات الاختبار

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

الجدول الزمني

• خطّط لأيام الاختبار على شكل فترات، مع وقت ثابت للفرز كل يوم.
• خصّص وقتًا لجولة إعادة اختبار بعد الإصلاحات.
• حدّد موعد اجتماع go/no-go، وادعُ اللجنة التوجيهية الآن.
• راجع تقويم إصدارات Salesforce أو Dynamics 365: إصدار للمنصة في منتصف UAT يغيّر ما تختبره.

معايير الدخول

• اكتمل اختبار النظام، ولا يوجد أي خلل Critical منه لا يزال مفتوحًا.
• بيئة الاختبار وحسابات الاختبار وبيانات الاختبار جاهزة.
• راجعت الأعمال حالات الاختبار.
• دُعي كل مختبِر وسجّل الدخول مرة واحدة.

أثناء UAT

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

الاجتماع اليومي القصير

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

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

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

الفرز

• اعقد الفرز كل يوم، مع الأعمال وفريق التطوير معًا.
• أعطِ كل مشكلة جديدة درجة خطورة وأولوية وشخصًا يصلحها.
• قرّر لكل واحدة: إصلاحها، أو رفضها، أو تحويلها إلى طلب تغيير.
• ضع طلبات التغيير في قائمة المهام المتراكمة (backlog)، لا في هذا الإصدار.

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

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

إغلاق UAT

ينتهي UAT بقرار. اتخذه بناءً على الحقائق، ودوّن من قرّر ماذا.

معايير الخروج

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

الاعتماد

• اطلب من مالك كل عملية الاعتماد: مقبول، أو مقبول بشروط، أو مرفوض.
• دوّن كل شرط، مع من ينفّذه ومتى.

Go/no-go

• اعقد اجتماع go/no-go والأرقام على الشاشة، لا من الذاكرة.
• سجّل القرار والشروط ومن اتخذه.

التقرير

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

بعد الانتقال إلى التشغيل الفعلي

• احتفظ بحالات الاختبار: فهي اختبار الانحدار لإصدار CRM التالي.
• دوّن ما يجب فعله بشكل مختلف في UAT التالي، ما دام الأمر حاضرًا في الذاكرة.