اختبار قبول المستخدم: كيف تفحص النظام قبل أن توقّع بالاستلام
اختبار قبول المستخدم (UAT) هو الفحص الأخير، الذي يجريه موظفوك بحالاتك الحقيقية، للتأكد من أن النظام الجديد يفعل ما تحتاجه المنشأة قبل أن تقبله وتدفع ثمنه. فجهّز سيناريوهات الاختبار من معايير القبول المتفق عليها ومن حالات حقيقية حديثة، ومنها الحالات المزعجة. واختبر في بيئة واقعية ببيانات منقولة، وسجّل كل مشكلة بدرجة خطورتها، واتفق مسبقًا على ما يجب إصلاحه قبل الإطلاق، وأعد اختبار الإصلاحات، ثم اعتمد كتابةً.
والاعتماد يطلق في العادة دفعةً، ويبدأ فترة الضمان. إنه آخر لحظة تملك فيها نفوذًا حقيقيًا، فهو يستحق وقتًا حقيقيًا.
الجواب المختصر
- موظفوك وحالاتك: اختبار القبول ليس اختبار المورّد، وليس عرضًا توضيحيًا.
- السيناريوهات تأتي من معايير القبول ومن حالات حقيقية حديثة، والاستثناءات منها.
- اختبر كل ما يلمسه المستخدم: الأدوار والصلاحيات، والعربية والإنجليزية، والمطبوعات، والأجهزة، والمسارات من أولها إلى آخرها.
- استخدم بيانات واقعية، ويُفضَّل أن تكون من تجربة لنقل البيانات.
- اتفق على معايير الخروج قبل بدء الاختبار، كألا تبقى مشكلة حرجة أو عالية الخطورة مفتوحة.
- اعتمد كتابةً، مع سرد أي مشكلات مقبولة ومواعيد إصلاحها.
«الاعتماد آخر لحظة تملك فيها نفوذًا حقيقيًا. فاختبر النظام بأكثر حالاتك فوضى، لا بنص العرض الذي أعدّه المورّد.» — عبدالقادر وهيبة، مؤسس «ذوات» ورئيسها التنفيذي
ما هو اختبار القبول، وما ليس هو
يجب أن يختبر المورّد عمله قبل تسليمه: يتحقق أن كل وظيفة تعمل، وأن الشيفرة متماسكة، وأن شيئًا قديمًا لم ينكسر. وهذا ضمان للجودة، وهو مهمته هو.
أما اختبار القبول فيجيب عن سؤال مختلف: هل يتيح هذا النظام لموظفينا أداء عملهم، في ظروفنا، وببياناتنا؟ ولا يستطيع الإجابة عنه إلا موظفوك. فالعرض المصقول على بيانات مُعدّة سلفًا يثبت القليل، وحالاتك الحقيقية تثبت الكثير.
من يختبر، ومتى
اختر الأشخاص الذين سيستخدمون النظام يوميًا، ومعهم مالك النتيجة. وحرّرهم من جزء من عملهم المعتاد طوال فترة الاختبار؛ فالاختبار المحشور في آخر يوم مزدحم لا يكشف إلا المشكلات الواضحة.
وضمّن اختبار القبول في الجدول الزمني من البداية، بدل أن تعامله على أنه ما تبقّى من وقت قبل الإطلاق. ويشرح مقال كم يستغرق بناء برنامجك؟ لماذا يكون الاختبار أول ما يُضغط حين يتأخر الجدول.
تجهيز سيناريوهات الاختبار
السيناريوهات الجيدة تأتي من مكانين.
معايير القبول المتفق عليها في المتطلبات، مكتوبةً بصيغة «بافتراض… عندما… فإن…». ويعرض مقال كتابة متطلبات البرنامج الصيغة، وكل معيار يصبح اختبارًا واحدًا على الأقل.
الحالات الحقيقية الحديثة، خصوصًا الصعبة منها: العميل الذي له عنوانا تسليم، والطلب المدفوع على أقساط، والمرتجع بعد إصدار الفاتورة، والطلب الذي قُدّم والمعتمِد مسافر.
ثم تأكد أن السيناريوهات تغطي:
- الأدوار والصلاحيات: ادخل بكل دور. هل يرى أمين المستودع الرواتب؟ هل يعتمد مدير فرع طلبًا لفرع آخر؟ يجب ألا يحدث ذلك.
- العربية والإنجليزية: كل شاشة ورسالة وبريد وملف PDF باللغتين، مع تخطيط صحيح من اليمين إلى اليسار، وترتيب وبحث سليمين بالعربية.
- المطبوعات والمستندات: الفواتير وإشعارات التسليم والتقارير، مطبوعةً وبصيغة PDF.
- الأجهزة: الهواتف والأجهزة اللوحية التي يستخدمها موظفوك فعلًا، لا متصفح الحاسوب وحده.
- المسارات الكاملة: طلب حتى الفاتورة والدفع والقيد المحاسبي، مع كل تكامل في الطريق.
- التقارير: مجاميع تطابق أرقامك أنت.
ويكفي قالب بسيط:
| السيناريو | الدور | الخطوات | النتيجة المتوقعة | نجح أم فشل | رقم المشكلة |
|---|---|---|---|---|---|
| اعتماد شراء بقيمة 450 ريالًا عُمانيًا | مدير فرع | فتح الطلب واعتماده | الحالة «معتمد»، وإشعار لأمين المستودع، وتسجيل الاعتماد | ||
| محاولة اعتماد 600 ريال عُماني | مدير فرع | فتح الطلب | اطلاع فقط، وإحالة إلى المدير العام |
البيئة والبيانات
اختبر في بيئة تحاكي البيئة الحية: الإعدادات نفسها، والتكاملات نفسها، مع الاتصال بنسخ اختبار من الخدمات الخارجية حيث وُجدت. واستخدم بيانات واقعية، ويُفضَّل أن تأتي من تجربة لنقل البيانات، لتختبر بالأسماء والمنتجات والأرصدة التي يعرفها موظفوك. ويتناول مقال نقل بياناتك إلى النظام الجديد تلك التجارب.
فالاختبار ببيانات مختلقة يخفي المشكلات التي تصنعها البيانات الحقيقية: الأسماء العربية الطويلة، والحروف غير المألوفة، والسجلات القديمة ذات الحقول الناقصة.
تسجيل المشكلات كما ينبغي
استخدم متتبعًا واحدًا مشتركًا مع المورّد. وسجّل لكل مشكلة خطوات إعادة إظهارها، وما توقعته، وما حدث بدلًا منه، ولقطة شاشة، ودرجة خطورة:
- حرجة: لا يمكن إتمام الإجراء، أو البيانات خاطئة أو في خطر.
- عالية: وظيفة رئيسية تفشل دون بديل معقول.
- متوسطة: وظيفة متأثرة مع وجود بديل.
- منخفضة: مسائل شكلية ومقترحات.
وافصل طلبات المزايا الجديدة عن العيوب؛ فكلاهما مهم، لكن العيوب وحدها هي التي تقرر الاعتماد.
معايير الخروج، متفق عليها مسبقًا
قبل بدء الاختبار، اتفقا على معنى «مقبول». ومن المعايير الشائعة:
- تنفيذ كل السيناريوهات المخططة؛
- ألا تبقى مشكلة حرجة أو عالية الخطورة مفتوحة؛
- سرد المشكلات المتوسطة، لكلٍّ منها موعد إصلاح متفق عليه؛
- مطابقة تجربة نقل البيانات؛
- تدريب المستخدمين الرئيسيين.
والاتفاق على ذلك مسبقًا يمنع الاعتماد من أن يتحول إلى مفاوضة تحت ضغط الموعد. ويوصي عبدالقادر وهيبة بكتابة المعايير قبل بدء البناء، ليصبح الاعتماد تحققًا من اتفاق لا جدالًا. ويجب أن يشير بند القبول في العقد إلى المعايير نفسها، كما يوصي مقال كيف تختار شريكًا برمجيًا في عُمان.
إعادة الاختبار والاعتماد
حين تصل الإصلاحات، أعد اختبار السيناريوهات التي فشلت، وكرّر عيّنة من التي نجحت، لأن الإصلاحات قد تكسر أشياء أخرى. ثم اعتمد كتابةً: ما الذي اختُبر، والنتيجة، والمشكلات المفتوحة المقبولة ومواعيد إصلاحها، وبداية فترة الضمان. واحتفظ بسجلات الاختبار؛ فهي دليل مفيد إن ظهرت مشكلة لاحقًا.
أخطاء شائعة
- اختبار المسار السعيد وحده: فالاستثناءات هي حيث تفشل الأنظمة.
- المديرون يختبرون بدل المستخدمين: فالمديرون يعرفون الإجراء كما صُمّم، والمستخدمون يعرفونه كما يجري.
- البيانات الوهمية: فهي تخفي مشكلات العالم الحقيقي.
- عدم تخصيص وقت: فالاختبار في الدقائق الفائضة لا يكشف إلا الأعطال الواضحة.
- الاعتماد تحت الضغط: فموعد الإطلاق ليس سببًا لقبول عيب حرج.
- تخطّي الواجهة العربية: فالأنظمة ثنائية اللغة تحتاج إلى اختبار باللغتين، على يد من يقرأ الاثنتين.
أسئلة شائعة
ما الفرق بين اختبار القبول واختبار المورّد؟ اختبار المورّد يتحقق أن البرنامج يعمل كما بُني، واختبار القبول يتحقق أنه يعمل لمنشأتك، بموظفيك وحالاتك وبياناتك. وأنت تحتاج إلى الاثنين.
كم يستغرق اختبار قبول المستخدم؟ يتوقف على حجم النظام وعدد السيناريوهات. وفي نسخة أولى مركّزة، كثيرًا ما يكون الأمر أسابيع لا أيامًا. فضمّنه في الجدول، مع تحرير وقت الموظفين له.
هل نطلق النظام مع مشكلات معروفة؟ نعم، إن كانت ثانوية، ولها بدائل، ومسرودة في وثيقة الاعتماد بمواعيد إصلاحها. أما الإطلاق مع مشكلات حرجة أو عالية الخطورة فيكلّف عادةً أكثر من تأجيل قصير.
ماذا لو وجدنا مشكلات بعد الاعتماد؟ يجب أن تغطي فترة الضمان المتفق عليها في العقد عيوب ما سُلّم. وبعدها تقع ضمن عقد الدعم. ويشرح مقال ما الذي يغطيه عقد الصيانة والدعم الفرق.
من يعتمد؟ مالك النتيجة، بناءً على رأي الموظفين الذين اختبروا. فالاعتماد قرار أعمال، لا قرار تقني.
المصادر: Agile Alliance — Given-When-Then
على وشك قبول نظام جديد، أو تخطط لواحد؟ تبني «ذوات» البرمجيات المخصصة بمعايير قبول يُتفق عليها مسبقًا، وتُختبر بحالاتك أنت. احجز مكالمة.