اختبار قبول

يُجرى اختبار القبول (بالإنجليزية:  Acceptance testing) في كلٍ من مجال الهندسة وأنظمتها الفرعية المختلفة بهدف تحديد ما إذا تم تلبية متطلبات المواصفات المعيارية أو التعاقدات القانونية. فهي قد تتضمن كلٌ من اختبار كيميائي (بالإنجليزية:  chemical test)، اختبار فيزيائي (بالإنجليزية:  physical test) أو حتى اختبارات الأداء (بالإنجليزية:  performance test).
وفي مجال هندسة الأنظمة، قد يتضمن اختبار القبول أداء اختبار الصندوق الأسود (بالإنجليزية:  Black-box testing) على نظامٍ (على سبيل المثال: جزء من برمجية، العديد من الأجزاء المصطنعة الآلية، أو دفعاتٍ من المنتجات الكيميائية قبيل تسليمها. وهو أيضاً معروف بأنه اختبار وظيفي (بالإنجليزية:  functional testing)، اختبار الصندوق الأسود، اختبار السؤال والجواب، اختبار تطبيقي، اختبار ثقة، اختبار نهائي، اختبار فاعلية، أو اختبار قبول مصنع.
غالباً ما يُفَرِّق مطوروا البرمجيات اختبارات القبول من خلال مزودي النظام عن اختبارات القبول من خلال العميل أو الزبون أو المستخدم قبيل قبول عملية نقل الملكية. وفي حالة البرمجيات، تُعْرَف اختبارات القبول التي يؤديها المستهلك باسم اختبار قبول المستهلك (بالإنجليزية:  user acceptance testing)، اختبار المستخدم النهائي (end-user testing)، اختبار (قبول) الموقع، أو اختبار (قبول) الحقل.
كما يُستخدم اختبار الدخان (بالإنجليزية:  smoke test) كاختبار قبول قبيل اخضاع مبناً لعملية الاختبار الأساسية.

نظرة عامة

غالباً ما تتضمن اختبارات القبول إجراء مجموعةٍ من الاختبارات على النظام الكامل. وكل اختبار فردي، معروفٍ كحالةٍ، يمارس حالة تشغيلٍ خاصةٍ لبيئة المستخدم أو سمةٍ من النظام، وسيسفر عن نجاح أو فشل، أو منطق، ناتجٍ ما. هذا ولا توجد عموماً هناك درجة ما للنجاح أو الفشل. فبيئة الاختبار غالباً ما يتم تصميمها لتكون بيئةً مثاليةً، أو أقرب إلى ذلك قدر المستطاع، وذلك بهدف توقع بيئة المستخدم، ومنها الحدود القصوى لمثل تلك البيئة. ومن ثم يجب أن تصاحَب حالات الاختبار تلك ببيانات مدخل حالة اختبار أو توصيف رسمي للأنشطة العملية الإجرائية (أو كليهما) ليتم الأداء عليها – والمقصود منها ممارسة الحالة الخاصة تماماً– والتوصيف الرسمي من النتائج المتوقعة.
غالباً ما يقوم مستهلكوا الأعمال التجارية والعملاء ببناء اختبارات/ معايير القبول (في تطوير البرمجيات الذكية (بالإنجليزية:  Agile software development)) ويتم صياغتها في سياق لغة نطاق الأعمال التجارية (بالإنجليزية:  business domain language). حيث تعتبر تلك الاختبارات عالية المستوى لاختبار وفحص اكتمال رواية المستخدم (user story) أو الروايات التي تم "أداؤها" خلال أي فترة عَدْوٍ أو تكرارٍ. فقد تم بناء تلك الاختبارات مثالياً من خلال التعاون فيما بين مستهلكي وعملاء الأعمال التجارية المختلفة، محللي الأعمال، المختبرين، والمطورين، على الرغم من ذلك، فإن مستهلكوا الأعمال التجارية (ملاك المنتج) هم المالكون الأساسيون الأُوَل لهذه الاختبارات. وبسبب أن روايات المستخدمين تجتاز معيار واختبار القبول، فإن أصحاب الأعمال قد يكونوا متأكدين حينئذٍ من حقيقة أن المطورين يتقدمون في الاتجاه الصحيح حول كيفية تخيل عمل البرنامج ومن ثم فمن الضروري أن تشتمل تلك الاختبارات على اختبارات منطق العمل بالإضافة إلى عناصر التحقق من فعالية واجهة المستخدم التفاعلية (لو لزمت الحاجة لذلك).
ويتم تصميم بطاقات اختبارات القبول خلال لقاءات تخطيط المسابقات أو تخطيطات الإعادة، وذلك قبيل بدء مرحلة التطوير، ومن ثم تتكون لدى المطورين فكرةٌ واضحةٌ عما يقومون بتطويره. إلا أننا نلاحظ أنه في بعض الأحيان (وبسبب التخطيط السيء!) قد تتجاوز اختبارات القبول العديد من الروايات (والتي لا يتم تنفيذها في السباق ذاته) وأن هناك سبلاً مختلفةً لاختبارها خلال السباقات الفعلية. ومن أحد الأساليب الشائعة، تقليد الواجهات الخارجية أو البيانات لمحاكاة الروايات الأخرى والتي قد لا يتم أدائها خلال عملية التكرار أو الإعادة (بسبب أن تلك القصص قد يكون لها أولوية أعمالٍ أقل نسبياً). فرواية المستخدم لا تعتبر كاملة حتى يتم اجتياز اختبارات القبول.

العملية

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

اختبارات قبول المستخدم

اختبار قبول المستخدم (بالإنجليزية:  User Acceptance Testing) هو عملية الحصول على تأكيدٍ بأن نظامٍ ما يلبي المتطلبات المتفق عليها بالتبادل فيما بين الأطراف. فخبير المادة الموضوعية، والذي غالباً ما يكون المالك أو زبون العنصر موضع الاختبار، يقوم بتوفير مثل ذلك التأكيد بعد المحاولة أو المراجعة. وفي عملية تطوير البرمجيات، يمثل اختبار قبول المستخدم أحد المراحل النهائية للمشروع وغالباً ما يقع قبيل قبول العميل أو الزبون للنظام الجديد.
وهنا يقوم مستخدموا النظام بأداء تلك الاختبارات، والتي يقوم المكورون باشتقاقها من بنود تعاقد العميل أو توصيف متطلبات المستخدم (بالإنجليزية:  Requirements analysis).
ويقوم مصمموا الاختبارات بإعداد اختباراتٍ رسميةٍ وتنويع مدىً واسعاً من مستويات الحدة. ونمطياً لا يجب أن يكون مصمم اختبارات قبول المستخدم منتج التكامل الرسمي ونظام حالات الاختبار (test case) لنفس النظام. وتلعب اختبارات قبول السمتخدم آلية التحقق الأخيرة لوظيفة العمل المطلوب والوظيفية المناسبة للنظام، وذلك بمحاكاة نفس ظروف وشروط الاستخدام الواقعي الفعلي بالنيابة عن العميل الذي يقوم بالدفع أو المستهلك الخاص. حيث لو عمل البرنامج كما كان متوقعاً أو بدون نشأة مسائلٍ أخرى أثناء الاستخدام الطبيعي، فإن المرء يصبح حينئذٍ قادراٍ على استنتاج نفس مستوى الثبات في الإنتاج بعقلانيةٍ مبررةٍ.
و من الطبيعي ألا تُرَكِّز اختبارات السمتخدم، والتي يقوم غالباً المستخدم النهائي أو العملاء بأدائها، على التعرف على المشكلات البسيطة مثل أخطاء الهجاء أو المشكلات التجميلية، أو حتى عيوب شوستوبر (showstopper defect)، مثل عمليات انهيار البرمجيات [software crashes)؛ وذلك لأن المختبرين والمطورين يقومون بتحديد مثل تلك المشكلات مسبقاً، إصلاحها وعلاجها، وذلك خلال مراحل الفحص الأولي للوحدة (unit testing)، فحص التكامل (integration testing)، فحص النظام نفسه.
وتعطي نتائج تلك الاختبارات الثقة للعملاء والمستخدمين حيث أنها توضح لهم كيفية عمل النظام في عملية الإنتاج فيما بعد. هذا وقد تكون هناك كذلك متطلباتٍ عقديةٍ أو قانونيةٍ لقبول النظام.

اختبارات القبول في البرمجة المفرطة

اُسْتُخْدِمَ مصطلح "اختبار القبول" في منهجيات تطوير البرمجيات الذكية، وخاصةً البرمجيات المفرطة (Extreme Programming)، ليشير بذلك إلى الفحص الوظيفي لرواية المستخدم من قِبَلِ فريق تطوير البرمجيات خلال مرحلة التنفيذ.
ويُحدد المستهلك السيناريوهات اللازمة لاختبار موعد تنفيذ رواية المستخدم بصورةٍ صحيحةٍ. حيث قد يكون للرواية واحداً أو أكثر من اختبارات القبول، مهما كان ما يستلزمه الأمر لضمان عمل الوظيفية. وتعتبر اختبارات القبول اختبارات نظام الصندوق الأسود. ويمثل كل اختبار قبول بعض النتائج المتوقعة من النظام. مما يجعل العملاء مسؤولين عن إثبات صحة اختبارات القبول ومراجعة نتائج الاختبارات لتقرير أية الاختبارات الفاشلة تتمتع بأعلى أولويةٍ. هذا وتُستخدم اختبارات القبول كاختبارات انحدار قبيل إطلاق عملية الإنتاج. وهنا لا تعتبر رواية المستخدم كاملةً حتى تجتاز اختباؤرات القبول الخاصة بها. وهذا يعني أن اختبارات القبول الجديدة يجب أن يتم بنائها لكل تكرارٍ (iteration) أو سيقوم فريق تطوير بالإقرار بفشل عملية التقدم.