اختبار القبول

لماذا يهم

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

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

أشكال اختبار القبول

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

• اختبار قبول المستخدم (User Acceptance Testing, UAT): يتحقق المستخدمون المقصودون من قدرتهم على أداء عملهم الحقيقي بالنظام، بعملياتهم وأدوارهم وببيانات واقعية، في بيئة تشغيل حقيقية أو محاكية لها.
• اختبار القبول التشغيلي (Operational Acceptance Testing, OAT): يتحقق موظفو التشغيل أو إدارة الأنظمة من قدرتهم على إبقاء النظام عاملاً: النسخ الاحتياطي والاستعادة، والتثبيت والترقية، والتعافي من الكوارث، وإدارة المستخدمين، والمراقبة.
• اختبار القبول التعاقدي (Contractual Acceptance Testing): يفحص البرمجيات المبنية حسب الطلب وفق معايير القبول الواردة في العقد، وينبغي الاتفاق عليها عند توقيعه.
• اختبار القبول التنظيمي (Regulatory Acceptance Testing): يفحص النظام وفق القوانين واللوائح التي يجب أن يلتزم بها، وقد تشهد جهة تنظيمية النتائج أو تدققها.
• اختبار ألفا (Alpha Testing): يستخدم المنتجَ عملاءُ محتملون أو حاليون، أو مشغّلون، أو فريق اختبار مستقل، لا المطورون، في موقع الجهة المطوِّرة.
• اختبار بيتا (Beta Testing): يستخدم العملاء المنتج في مواقعهم وعلى أجهزتهم، بعد اختبار ألفا أو من دونه، فيكشفون عيوباً مرتبطة ببيئات يصعب على الفريق إعادة إنتاجها.

معايير القبول هي أساس الاختبار

يحتاج كل اختبار قبول إلى أساس اختبار (Test Basis) يحدد معنى «مقبول». ففي قصة المستخدم (User Story) هو معايير القبول (Acceptance Criteria): الشروط التي يجب أن يستوفيها التنفيذ ليقبله أصحاب المصلحة. ويعتمد اختبار قبول المستخدم أيضاً على عمليات العمل التي يتبعها المستخدمون، ويستخدم القبول التعاقدي معايير العقد، والتنظيمي اللائحة نفسها، والتشغيلي المتطلبات التشغيلية، مثل إجراءات النسخ الاحتياطي والتعافي.

والمعايير الجيدة يُتفق عليها قبل بناء العمل، فيكون القبول فحصاً لا تفاوضاً، وتكون قابلة للاختبار: إذا قرأ المستخدم والمطور والمختبِر المعيار نفسه وصلوا إلى الحكم نفسه. وصياغتها على شكل قواعد أو سيناريوهات Given/When/Then موضوع درس خاص لاحقاً في خريطة التعلم؛ وهنا يكفي أن تميّز المعيار الغامض.

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

جرّبها: مولّد معايير القبول جرّبها: مراجع معايير القبول بالذكاء الاصطناعي

من يقرّر القبول

القبول قرار، وهو لمن يتحملون مخاطر العمل الناتجة عن استخدام النظام، لا لمن بنوه أو اختبروه. سمِّ صاحب القرار لكل شكل في خطة الاختبار أو في العقد قبل بدء الاختبار.

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

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

مثال تطبيقي: قبول وحدة الإجازات في بوابة الموارد البشرية

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

• AC-1 وAC-2 (قبول المستخدم): يقدّم أربعة من موظفي الموارد البشرية وثلاثة مديرين مباشرين طلبات ويعتمدونها ويرفضونها ويلغونها مدة ثلاثة أيام، على نسخة في بيئة staging ببيانات مُجهَّلة الهوية.
• AC-3 (القبول التعاقدي): يُعدّ فريق ضمان الجودة في الشركة، وهو مستقل عن المورّد، موظفين بأرصدة معروفة، ويتحقق من كل رصيد بعد الاعتماد، بما في ذلك أنصاف الأيام.
• AC-4 وAC-5 (القبول التشغيلي): يستعيد فريق تشغيل تقنية المعلومات النسخة الاحتياطية لليلة الماضية على خادم نظيف، ويطابق التصدير الليلي إلى نظام الرواتب مع المصدر.
• AC-6 (القبول التنظيمي): يتحقق مسؤول الامتثال في الموارد البشرية من أنواع الإجازات وسجلاتها وفق متطلبات نظام العمل التي تنطبق على الشركة.

سجل القبول: وحدة الإجازات 1.0، build 1.0.4، بيئة staging

ID     Form         Result   Evidence
AC-1   UAT          Passed   UAT-01..UAT-06
AC-2   UAT          Passed   UAT-07..UAT-10
AC-3   Contractual  Failed   DEF-112 (Major)
AC-4   OAT          Passed   OPS-01 restore log
AC-5   OAT          Passed   OPS-02 payroll export totals
AC-6   Regulatory   Passed   COMP-01 compliance checklist

عيب مفتوح: DEF-112 (رئيسي، Major): تُخصم إجازة نصف اليوم يوماً كاملاً بدل 0.5
توصية ضمان الجودة: القبول بعد نجاح اختبار التأكيد للعيب DEF-112
القرار (مدير الموارد البشرية): قبول مشروط، والتشغيل الفعلي بعد الإصلاح

جرّبها: المتطلبات ← حالات اختبار جرّبها: قصة المستخدم ← سيناريوهات اختبار

أسئلة شائعة

المراجع

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• ISTQB GlossaryISTQBالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
• Certified Tester Acceptance Testing (CT-AcT)ISTQB · 2019منهج ISTQB التخصصي لاختبار القبول: اختبار قبول المستخدم والقبول التعاقدي والتنظيمي، واختبارا ألفا وبيتا، وتعاون المختبِرين مع مالكي المنتج ومحللي الأعمال.