اختبار قبول المستخدم UAT لنظام LMS: السيناريوهات ومعايير القبول

ما الذي يقرره UAT ولا تقرره اختبارات المورد؟

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

لهذا لا يُستبدل UAT بالعرض التوضيحي الذي رأيته قبل الشراء. العرض كان على بيئة المورد وبيانات تشبه بياناتك، وكانت غايته المقارنة بين المزودين، كما في دليل سيناريوهات العرض التوضيحي. UAT على إعداداتك أنت، وبياناتك أنت، ونتيجته محضر قبول يُوقّع عليه قبل الإطلاق.

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

خطة UAT: المشاركون والبيئة والبيانات

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

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

سيناريوهات اختبار UAT لنظام LMS حسب الدور

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

النتيجة المتوقعة هي ما يجعل السيناريو قابلًا للحكم. «يستطيع المدير رؤية التقارير» لا يُحكم عليه، أما «يرى المدير فريقه فقط، والأرقام تطابق ما في تقرير مسؤول التدريب لنفس الفريق» فيُحكم عليه بنعم أو لا.

سيناريوهات تعبر الأدوار من البداية إلى النهاية

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

وأضف إليه بحسب جهتك:

• انتقال موظف بين إدارتين: يُعدَّل في نظام الموارد البشرية، فيبقى سجله التدريبي كاملًا، وتُسند إليه برامج إدارته الجديدة، وينتقل من تقرير مديره القديم إلى الجديد.
• مغادرة موظف: يُغلق حسابه في نظام الهوية فلا يستطيع الدخول، ويبقى سجله محفوظًا ومتاحًا للتقارير التاريخية.
• تجديد شهادة إلزامية: موظف شهادته تقترب من الانتهاء (اضبط تاريخها في بيانات الاختبار)، فيُعاد إسناد البرنامج، ويصله التذكير ثم لمديره، ويظهر غير ممتثل بعد الانتهاء حتى يجدد، كما تصف دورة الشهادة في التدريب الإلزامي في المنصة.
• برنامج مدمج: جزء إلكتروني ثم ورشة حضورية بحضور QR ثم اختبار نهائي، وتصدر الشهادة بعد استيفاء الشرطين معًا.

الاختبارات السلبية: ما يجب ألا يحدث

معظم المختبرين يتحققون مما يجب أن يعمل، وقلة يتحققون مما يجب أن يُمنع. في منصة تحمل نتائج وسجلات موظفين، تسرب البيانات بين الفروع عيب أخطر من زر لا يعمل. خصص جزءًا من الجولة للمحاولات الممنوعة، ونفذها بحسابات الأدوار الفعلية لا بحساب مسؤول النظام:

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

اختبار التقارير: طابقها بأرقام تعرفها

التقرير الذي «يعمل» قد يعطي رقمًا خاطئًا. لا تحكم على التقارير بشكلها؛ اختبرها برقم تعرفه مسبقًا. قبل الجولة، جهّز عينة تعرف نتيجتها: فرع فيه عدد معروف من الموظفين، أكمل منهم عدد معروف برنامجًا إلزاميًا، وتنتهي شهادات عدد معروف منهم خلال الشهر. ثم اطلب من مدير الفرع ومسؤول التدريب استخراج التقرير نفسه، كل بحسابه:

• هل يطابق رقم الإكمال العدد المعروف، وهل الأسماء المتأخرة هي نفسها؟
• هل يطابق تقرير مدير الفرع الجزء الخاص بفرعه في تقرير مسؤول التدريب؟
• هل يطابق الملف المصدّر إلى Excel أو PDF ما على الشاشة بعد التصفية؟
• هل يصل التقرير المجدول بالبريد في موعده، ولمن يحق له فقط؟
• هل تظهر السجلات التاريخية المرحّلة في الساعات التدريبية للفترات السابقة؟

مكتبة التقارير في المنصة تتبع صلاحيات من يطلبها، وتعكس البيانات الحالية لحظة الاستعراض، وتُصدَّر بالتصفية. وإن طلبت تقارير خاصة ضمن نطاق المشروع، فهي تطوير يُختبر بالطريقة نفسها مع ميزة إضافية: قارن تعريف كل حقل فيها بما كُتب في وثيقة المتطلبات.

معايير القبول وتصنيف العيوب

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

ثم اكتب معايير القبول بصيغة تُقاس، مثل: «نُفّذت كل السيناريوهات المصنفة إلزامية، ولا عيب حرجًا مفتوحًا، ولا عيب عاليًا في السيناريوهات الإلزامية، وكل عيب متوسط له مالك وموعد إصلاح، واعتمد ممثل كل دور نتائجه». ولاحظ الفرق بين العيب وطلب التغيير: «التقرير لا يحسب المغادرين بشكل صحيح» عيب، أما «نريد عمودًا جديدًا لم يُطلب في المتطلبات» فطلب تغيير يُسجل ويُقيَّم خارج قرار القبول، وإلا لن تنتهي الجولة.

قرار الإطلاق: متى تقول إن المنصة جاهزة؟

في نهاية الجولة، وبعد إعادة اختبار ما أُصلح، يجتمع صاحب القرار وممثلو الأدوار وتقنية المعلومات ومدير مشروع المورد، ويقررون بأحد ثلاثة قرارات:

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

سيناريو: شركة نقل بست محطات تختبر قبل الإطلاق

مثال افتراضي للتوضيح شركة نقل بالحافلات بين المدن فيها نحو 2,600 موظف: سائقون وفنيو صيانة في ست محطات رئيسية، وموظفو تذاكر وخدمة عملاء، ومقر رئيسي. المكتبيون يدخلون بحسابات Active Directory، والسائقون بحسابات المنصة من جوالاتهم، وبيانات الموظفين تصل من نظام الموارد البشرية بملف مجدول، والسجلات التاريخية لأربع سنوات رُحّلت من جداول Excel.

كتبت الشركة 48 سيناريو: 14 حسب الدور، و5 متكاملة، و12 سلبية للصلاحيات، و9 للتقارير، و8 لبرامجها الإلزامية بأسمائها (السلامة على الطريق، والإسعافات الأولية، والتعامل مع الركاب). شارك 16 مختبرًا، منهم أربعة سائقين ومدير محطة ومدرب سلامة متعاقد. وانتهت الجولة الأولى بهذه النتيجة:

تبيّن أن العيبين العاليين والعيب الحرج كلها في التهيئة وخريطة البيانات لا في المنصة: ربط خاطئ للمحطات، ومسمى وظيفي في ملف الموارد البشرية لم يرد في القاعدة، وملف ترحيل لمحطة واحدة بصيغة تاريخ مختلفة. أُصلحت الثلاثة، وأُعيد اختبار 9 سيناريوهات متأثرة، وأُطلقت المنصة لمحطتين أولًا كما كان مخططًا. لو اختبرت الشركة بحساب مسؤول النظام وحده، لما ظهر العيب الحرج، لأن مسؤول النظام يرى كل المحطات أصلًا.

أخطاء تفسد اختبار القبول

• اختبار بحساب مسؤول النظام: يرى كل شيء ويستطيع كل شيء، فلا يكشف عيوب الصلاحيات ولا تجربة المتعلم.
• إغفال الجوال: يختبر الجميع من الحاسب، ثم يدخل أغلب المتعلمين الميدانيين من الجوال يوم الإطلاق.
• دمج UAT مع التدريب: المختبر الذي يتعلم المنصة أثناء الاختبار يسجل صعوبة الاستخدام عيبًا، ويغفل العيوب الحقيقية. درّبه باختصار قبل الجولة.
• قبول «سيُصلح بعد الإطلاق» لعيب حرج: ما يُكشف من بيانات أو يُفسد من سجلات بعد الإطلاق لا يُستعاد بإصلاح.
• إعادة اختبار الإصلاح وحده: إصلاح في قاعدة إسناد قد يكسر قاعدة أخرى. أعد اختبار السيناريوهات المرتبطة لا السيناريو الذي فشل فقط.
• معايير قبول بلا مالك: إن لم يكن هناك من يوقّع، سيُطلق النظام لأن الموعد وصل، لا لأنه جاهز.

الأسئلة الشائعة

الخلاصة: اكتب ما يعنيه «جاهز» قبل أن تختبر

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

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