اختبارات قبول نظام حجز المواعيد: سيناريوهات يجب تنفيذها قبل الاستلام

ما الذي يميز اختبار القبول عن العرض التوضيحي والتجربة؟

تمر المنشأة قبل التشغيل بأربع محطات تتشابه أسماؤها وتختلف وظائفها. الخلط بينها هو أول سبب لاستلام نظام لم يُختبر: يظن الفريق أن ما رآه في العرض التوضيحي قبل الشراء كافٍ، أو يؤجل كل شيء إلى «التجربة» بعد الإطلاق.

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

شروط الدخول: متى يكون النظام جاهزًا للاختبار؟

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

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

كيف تكتب حالة اختبار يُحكم عليها بنعم أو لا؟

الحالة الضعيفة تقول «التأكد من عمل التذكيرات». الحالة القابلة للحكم تحدد الشرط المسبق والخطوات والنتيجة المتوقعة، فلا يختلف مختبِران على نتيجتها. استخدم هذا القالب لكل حالة:

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

سيناريوهات القبول حسب دورة الموعد

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

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

الحالات الحدية التي لا تظهر إلا في يوم تشغيل حقيقي

أغلب العيوب التي تظهر بعد الإطلاق لم تكن في المسار الطبيعي، بل في أطرافه. أضف هذه الحالات حتى لو بدت نادرة، لأنها تتكرر أسبوعيًا في منشأة نشطة:

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

تصنيف العيوب: ما الذي يوقف الاستلام وما الذي لا يوقفه؟

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

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

مثال: هل يُوقَّع الاستلام اليوم؟

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

الحساب: نسبة النجاح العامة بعد إعادة الاختبار = 87 ÷ 90 ≈ 97%، وهي رقم يبدو مطمئنًا. لكن القاعدة لا تنظر إليه أولًا: الحالات الإلزامية الناجحة 59 من 60، أي أن حالة إلزامية واحدة لم تنجح بعد. فإن كانت هي إحدى الحالتين المتوقفتين لأن نظام المحاسبة لم يوفر بيئة اختبار، فالقرار ليس «رفض» ولا «استلام كامل»، بل استلام مشروط يكتب في المحضر أن هذه الحالة تُختبر فور توفر البيئة، وأن التكامل المحاسبي لا يُفعّل قبل نجاحها. أما لو كانت الحالة الإلزامية فاشلة بسبب النظام نفسه، فلا توقيع حتى تُصلح ويُعاد اختبارها.

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

من يختبر، ومن يوقّع محضر الاستلام؟

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

أين يدخل اختبار القبول في تنفيذ «نظام حجز وإدارة المواعيد»؟

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

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

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

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

الخلاصة: الاستلام قرار تحكمه قاعدة مكتوبة

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