معظم عمليات الإطلاق المتعثرة في مشاريع Odoo تفشل لسبب بسيط: لم يختبر أحد النظام بالطريقة التي تعمل بها الشركة فعلاً. تمت مراجعة الإعدادات شاشة بشاشة، وقُدّمت بعض العروض التوضيحية، ووافق الجميع، ثم في أول يوم عمل تعذّرت فوترة طلب لأن شرط الدفع الذي يستخدمه فريق المبيعات يومياً لم يُضبط أصلاً. اختبار قبول المستخدم، أو UAT، هو المرحلة التي تلتقط هذا النوع من المفاجآت. وهو أيضاً أكثر مرحلة تُختصر إلى إجراء شكلي من يومين في نهاية المشروع، تحديداً حين تكون الميزانية قد ضاقت والجميع يريد الانتهاء.
فيما يلي كيف تُدير هذه المرحلة بحيث تستحق مكانها في الخطة.
اختبار القبول ليس عرضاً توضيحياً ولا مطاردة أخطاء
في العرض التوضيحي يقود الاستشاري. في اختبار القبول يقود موظفوك، على عملياتهم هم، بينما يراقب الاستشاري ويدوّن. الفارق أكبر مما يبدو: من بنى الإعدادات يتجنّب دون وعي المسارات التي تكسرها، أما مشرف المستودع لديك فسيدخل إليها من المحاولة الأولى.
كما أنه ليس اختباراً فنياً للنظام. صحة الرقم الذي يُخرجه حقل محسوب مسؤولية فريق التنفيذ، ويجب إغلاقها قبل فتح مرحلة القبول. اختبار القبول يجيب على سؤال أضيق وأهم: هل تستطيع هذه الشركة أن تعمل على هذا النظام الأسبوع المقبل؟
اكتب السيناريوهات من العمليات لا من الوحدات
الخطأ الأكثر شيوعاً هو خطة اختبار مرتّبة على شكل مبيعات، مخزون، محاسبة، مع قائمة شاشات تُفتح في كل قسم. العمل الحقيقي يعبر الوحدات، والأعطال تسكن في المفاصل بينها. اكتب بدلاً من ذلك سيناريوهات متكاملة من البداية إلى النهاية:
- عرض سعر لعميل جديد تماماً، مروراً بالتسليم والفاتورة ودفعة جزئية وإشعار دائن.
- طلب شراء، ثم استلام كمية أقل من المطلوبة، ثم مطابقة فاتورة المورد عليها.
- إقفال شهري على بيانات اختبارية: التسويات، قيد استحقاق، ميزان المراجعة، والتقارير التي يرفعها فريق المالية فعلاً.
- مسار استثنائي واحد على الأقل لكل عملية: طلب ملغى، مرتجع، خصم يحتاج موافقة، فاتورة سُدّدت مرتين.
غطِّ الحركات التي تشكّل معظم حجم عملك، إضافة إلى الاستثناءات التي يكلّف تعطّلها أكثر من غيرها. ولا بد أن يحدد كل سيناريو الدور الذي ينفّذه، والبيانات التي يبدأ منها، والخطوات، والنتيجة المتوقعة. إن لم يستطع أحد تحديد النتيجة المتوقعة قبل التنفيذ، فالاختبار لا يمكن أن يفشل، والاختبار الذي لا يمكن أن يفشل ليس اختباراً.
اختبر على بيانات مُرحّلة وفي بيئة منفصلة
البيانات التجريبية نظيفة، والبيانات النظيفة تخفي المشكلات التي ستتعايش معها لاحقاً: سجلات عملاء مكررة، أصناف بلا وحدة قياس، طلبات قديمة بهيكل خصومات لم يعد أحد يتذكره، أرصدة افتتاحية لا تتطابق. هذه لا تظهر إلا حين تلتقي السجلات الحقيقية بالعمليات الحقيقية.
نفّذ اختبار القبول على بياناتك المُرحّلة في بيئة staging تحاكي ما ستكون عليه بيئة الإنتاج، ولا تنفّذه أبداً على بيئة الإنتاج نفسها. وتأكد قبل البدء من تحييد البيئة: تعطيل البريد الصادر أو إعادة توجيهه، ووضع بوابات الدفع في وضع الاختبار، وقطع أي إرسال إلى بوابة ضريبية أو مصرفية خارجية. فاتورة اختبارية تصل إلى عميل حقيقي تكلّفك من الثقة أكثر مما تكلّفه المرحلة كلها من ساعات عمل.
اختر مختبرين يستخدمون النظام يومياً
المدراء يعتمدون العملية، والموظفون يعيشون فيها. اعتماد مدير قسم بعد جولة تعريفية يخبرك أن التصميم يبدو سليماً، لا أن العمل عليه ممكن. ضع أمام الشاشات من سيُدخل 50 حركة في اليوم، وامنحهم أوقاتاً مخصصة ومحمية لذلك. فاختبار القبول المحشور في فراغات يوم عمل عادي ينتج قائمة علامات صح بلا أي ملاحظة حقيقية.
سجّل الملاحظات في مكان واحد وصنّفها بصدق
سجل واحد، بصيغة واحدة، ولا ملاحظات تعيش في محادثات WhatsApp الشخصية. كل ملاحظة تحتاج إلى السيناريو، وما حدث، وما كان متوقعاً، ولقطة شاشة. ثم صنّفها:
- معطّل: الشركة لا تستطيع إتمام الحركة. يُصلح قبل الإطلاق دون نقاش.
- كبير: يوجد حل بديل لكنه مكلف أو معرّض للخطأ. يُصلح، أو يُقبل كتابةً بمالك محدد وتاريخ.
- بسيط: شكلي أو نادر التكرار. يُجمّع لما بعد الإطلاق.
- طلب تغيير: النظام ينفّذ ما اتُّفق عليه، لكن أحدهم صار يريد شيئاً مختلفاً.
الفئة الرابعة هي حيث تموت الجداول الزمنية بهدوء. هي فئة مشروعة، لكنها ليست خللاً. سجّلها وسعّرها وجدولها بشكل منفصل. فالسماح لطلبات التغيير بالدخول إلى المشروع عبر سجل اختبار القبول هو الطريقة التي يتحول بها تنفيذ من 4 أشهر إلى 7 أشهر دون أن يقرر أحد ذلك صراحةً.
اجعل الاعتماد النهائي يعني شيئاً محدداً
عبارة «اكتمل اختبار القبول» في تقرير حالة ليست اعتماداً. الاعتماد المفيد يكون لكل عملية على حدة، ويمنحه مالك تلك العملية، وينص على أن كل ملاحظة معطّلة أُغلقت وأُعيد اختبارها، وأن كل ملاحظة كبيرة إما أُغلقت أو قُبلت رسمياً بمالك محدد، وأن كل طلب تغيير انتقل إلى قائمة أعمال ما بعد الإطلاق بتاريخ محدد. وإن لم يكن مالك العملية قد نفّذ السيناريو بنفسه، فهو يعتمد رأي شخص آخر.
احسب حساب الجولة الثانية
اختبار قبول لا يخرج بأي ملاحظة لم يُنفَّذ فعلاً. خطط لجولتين: الأولى تُخرج الملاحظات، والثانية تؤكد الإصلاحات، والأهم أنها تؤكد أن الإصلاحات لم تكسر شيئاً آخر. إعادة اختبار السيناريو المُصلح وحده لا تكفي، لأن تعديل قاعدة تسعير أو مسار موافقة نادراً ما يبقى داخل وحدته.
الفرق التي تنطلق بهدوء ليست عادةً صاحبة أقل عدد من الملاحظات، بل هي التي اكتشفت مشكلاتها في بيئة اختبارية قبل ثلاثة أسابيع، ومعها وقت لتقرر ما تُصلحه وما تتعايش معه. إن كنت تخطط لهذه المرحلة الآن، فصفحة خدمة تطبيق Odoo توضح كيف نبني الاختبار والتسليم حول تاريخ الإطلاق.