اختبار قبول اودو: كيف تتأكد أن دورة عملك تعمل كما تحتاجها قبل الإطلاق؟

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

ما الفرق بين اختبار القبول وبقية الاختبارات؟

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

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

كيف تبدو حالة القبول التي يفهمها المالك؟

خذ مثالًا من المشتريات. في اودو 19.0 يمكن ضبط سياسة مراقبة الفواتير لكل منتج بحسب الكميات المطلوبة أو الكميات المستلمة. عند تأكيد أمر الشراء تصبح مسودة الفاتورة بالكمية المطلوبة متاحة للإنشاء، وهي خيار أمام المستخدم وليست فاتورة مرحّلة تلقائيًا. وعند اختيار الكميات المستلمة تُنشأ المسودة من الكمية التي استُلمت فعلًا، جزئيًا كانت أو كاملة. ومع المطابقة الثلاثية تظهر حالة «Should Be Paid»، وإذا عُدّل السعر أو الكمية أو البنود في المسودة تظهر إشارة «Exception» (توثيق اودو 19.0، «Control policies»؛ المرجع).

مثال افتراضي لمعيار قبول: أمر شراء بـ 100 وحدة بسعر 50 ريالًا للوحدة، استُلمت منه 60 وحدة ولا توجد فاتورة سابقة، والسياسة على الكميات المستلمة.

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

كيف نختبر الدورة بين الأقسام؟

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

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

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

ما الذي يحدد جهد الاختبار؟

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

بيئة الاختبار والصلاحيات

نحدد بيئة مخصصة لاختبار القبول ونراجع عزل اتصالاتها الخارجية قبل البدء. يوثق اودو 19.0 تعطيل عناصر مثل البريد الصادر ومزودي الدفع ومزامنة البنك في القواعد المحايدة للاختبار، ومنها النسخ التجريبية وبيئات التطوير والتجهيز على Odoo.sh. وتدخل الموصلات المخصصة والخارجية في المراجعة بحسب إعداداتها، كي تبقى الرسائل والمدفوعات الحقيقية خارج هذه التجربة (توثيق اودو 19.0، «Neutralized database»؛ المرجع).

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

الاستثناءات والعيوب

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

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

أسئلة شائعة

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

من يشارك من جانبنا؟ مستخدم من كل دورة رئيسية، ومسؤول المالية لمراجعة الأثر المحاسبي، وشخص يملك صلاحية القبول باسم الإدارة.

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

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

المراجع

1. ISTQB، Certified Tester Foundation Level Syllabus v4.0.1 (15 سبتمبر 2024)، إعداد Renzo Cerquozzi وآخرين كما هو مذكور في الوثيقة. حقوق النشر للمؤلفين وISTQB؛ مرجع لممارسات اختبار البرمجيات: الملف الأصلي.
2. توثيق اودو 19.0 الرسمي: «Control policies» ضمن ضبط فواتير الشراء، و«Neutralized database»، و«Access rights».

خطوتك التالية مع تودو اوبس

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