اختبار قبول  يُجرى اختبار القبول في كلٍ من مجال الهندسة وأنظمتها الفرعية المختلفة بهدف تحديد ما إذا تمت تلبية متطلبات المواصفات المعيارية أو التعاقدات القانونية. فهي قد تتضمن كلٌ من اختبار كيميائي ، اختبار فيزيائي أو حتى اختبارات الأداء .  وفي مجال هندسة الأنظمة، قد يتضمن اختبار القبول أداء اختبار الصندوق الأسود على نظامٍ (على سبيل المثال: جزء من برمجية، العديد من الأجزاء المصطنعة الآلية، أو دفعاتٍ من المنتجات الكيميائية قبيل تسليمها. وهو أيضاً معروف بأنه اختبار وظيفي ، اختبار الصندوق الأسود، اختبار السؤال والجواب، اختبار تطبيقي، اختبار ثقة، اختبار نهائي، اختبار فاعلية، أو اختبار قبول مصنع.  غالباً ما يُفَرِّق مطورو البرمجيات اختبارات القبول من خلال مزودي النظام عن اختبارات القبول من خلال العميل أو الزبون أو المستخدم قبيل قبول عملية نقل الملكية. وفي حالة البرمجيات، تُعْرَف اختبارات القبول التي يؤديها المستهلك باسم اختبار قبول المستهلك ، اختبار المستخدم النهائي (end-user testing)، اختبار (قبول) الموقع، أو اختبار (قبول) الحقل.  كما يُستخدم اختبار الدخان كاختبار قبول قبيل إخضاع مبناً لعملية الاختبار الأساسية.  غالباً ما تتضمن اختبارات القبول إجراء مجموعةٍ من الاختبارات على النظام الكامل. وكل اختبار فردي، معروفٍ كحالةٍ، يمارس حالة تشغيلٍ خاصةٍ لبيئة المستخدم أو سمةٍ من النظام، وسيسفر عن نجاح أو فشل، أو منطق، ناتجٍ ما. هذا ولا توجد عموماً هناك درجة ما للنجاح أو الفشل. فبيئة الاختبار غالباً ما يتم تصميمها لتكون بيئةً مثاليةً، أو أقرب إلى ذلك قدر المستطاع، وذلك بهدف توقع بيئة المستخدم، ومنها الحدود القصوى لمثل تلك البيئة. ومن ثم يجب أن تصاحَب حالات الاختبار تلك ببيانات مدخل حالة اختبار أو توصيف رسمي للأنشطة العملية الإجرائية (أو كليهما) ليتم الأداء عليها – والمقصود منها ممارسة الحالة الخاصة تماماً– والتوصيف الرسمي من النتائج المتوقعة.  غالباً ما يقوم مستهلكو الأعمال التجارية والعملاء ببناء اختبارات/ معايير القبول (في تطوير البرمجيات الذكية ) وتتم صياغتها في سياق لغة نطاق الأعمال التجارية . حيث تعتبر تلك الاختبارات عالية المستوى لاختبار وفحص اكتمال رواية المستخدم (user story) أو الروايات التي تم «أداؤها» خلال أي فترة عَدْوٍ أو تكرارٍ. فقد تم بناء تلك الاختبارات مثالياً من خلال التعاون فيما بين مستهلكي وعملاء الأعمال التجارية المختلفة، محللي الأعمال، المختبرين، والمطورين، على الرغم من ذلك، فإن مستهلكوا الأعمال التجارية (ملاك المنتج) هم المالكون الأساسيون الأُوَل لهذه الاختبارات. وبسبب أن روايات المستخدمين تجتاز معيار واختبار القبول، فإن أصحاب الأعمال قد يكونوا متأكدين حينئذٍ من حقيقة أن المطورين يتقدمون في الاتجاه الصحيح حول كيفية تخيل عمل البرنامج ومن ثم فمن الضروري أن تشتمل تلك الاختبارات على اختبارات منطق العمل بالإضافة إلى عناصر التحقق من فعالية واجهة المستخدم التفاعلية (لو لزمت الحاجة لذلك).  ويتم تصميم بطاقات اختبارات القبول خلال لقاءات تخطيط المسابقات أو تخطيطات الإعادة، وذلك قبيل بدء مرحلة التطوير، ومن ثم تتكون لدى المطورين فكرةٌ واضحةٌ عما يقومون بتطويره. إلا أننا نلاحظ أنه في بعض الأحيان (وبسبب التخطيط السيئ!) قد تتجاوز اختبارات القبول العديد من الروايات (والتي لا يتم تنفيذها في السباق ذاته) وأن هناك سبلاً مختلفةً لاختبارها خلال السباقات الفعلية. ومن أحد الأساليب الشائعة، تقليد الواجهات الخارجية أو البيانات لمحاكاة الروايات الأخرى والتي قد لا يتم أداؤها خلال عملية التكرار أو الإعادة (بسبب أن تلك القصص قد يكون لها أولوية أعمالٍ أقل نسبياً). فرواية المستخدم لا تعتبر كاملة حتى يتم اجتياز اختبارات القبول.  ويتم إجراء مجموعة اختبارات القبول ضد بيانات الإدخال المتوفرة أو باستخدام نسخة اختبار القبول لتوجيه المختبرين. ثم يتم مقارنة النتائج مع النتائج المتوقعة. فلو وُجِدَ هناك تماثلاً وتناسباً صحيحاً لكل حالةٍ، فمن المقرر اجتياز مجموعة الاختبارات. وإلا، فمن المحتمل رفض النظام أو قبوله بشروطٍ تم الاتفاق عليها مسبقاً فيما بين الراع والمُصَنِّع.  ويتمثل الهدف في منح الثقة في أن النظام الذي يتم تسليمه يُقابل ويلبي متطلبات العمل لكلٍ من الرعاة والمستخدمين. هذا وقد تلعب مرحلة القبول كذلك دور بوابة الجودة الأخيرة، حيث قد يتم الكشف فيها عن أي عيوب جودةٍ لم تكن قد ظهرت أو استُشْعِرَت مسبقاً.  مما يجعل أحد الأهداف الرئيسية لاختبار القبول يتمثل في أنه بمجرد استكماله بنجاح، وتلبية معايير القبول الإضافية المتاحة (المتفق عليها تعاقدياً)، فإن الرعاة سيوقِّعون على النظام برضائهم عن العقد (والذي تم الاتفاق عليه مسبقاً فيما بين الراعي والمُصَنِّع)، ثم يقومون بتسليم استحقاقات المدفوعات النهائية.  اختبار قبول المستخدم هو عملية الحصول على تأكيدٍ بأن نظامٍ ما يلبي المتطلبات المتفق عليها بالتبادل فيما بين الأطراف. فخبير المادة الموضوعية، والذي غالباً ما يكون المالك أو زبون العنصر موضع الاختبار، يقوم بتوفير مثل ذلك التأكيد بعد المحاولة أو المراجعة. وفي عملية تطوير البرمجيات، يمثل اختبار قبول المستخدم أحد المراحل النهائية للمشروع وغالباً ما يقع قبيل قبول العميل أو الزبون للنظام الجديد.  وهنا يقوم مستخدموا النظام بأداء تلك الاختبارات، والتي يقوم المكورون باشتقاقها من بنود تعاقد العميل أو توصيف متطلبات المستخدم .  ويقوم مصمموا الاختبارات بإعداد اختباراتٍ رسميةٍ وتنويع مدىً واسعاً من مستويات الحدة. ونمطياً لا يجب أن يكون مصمم اختبارات قبول المستخدم منتج التكامل الرسمي ونظام حالات الاختبار (test case) لنفس النظام. وتلعب اختبارات قبول السمتخدم آلية التحقق الأخيرة لوظيفة العمل المطلوب والوظيفية المناسبة للنظام، وذلك بمحاكاة نفس ظروف وشروط الاستخدام الواقعي الفعلي بالنيابة عن العميل الذي يقوم بالدفع أو المستهلك الخاص. حيث لو عمل البرنامج كما كان متوقعاً أو بدون نشأة مسائلٍ أخرى أثناء الاستخدام الطبيعي، فإن المرء يصبح حينئذٍ قادراٍ على استنتاج نفس مستوى الثبات في الإنتاج بعقلانيةٍ مبررةٍ.  و من الطبيعي ألا تُرَكِّز اختبارات السمتخدم، والتي يقوم غالباً المستخدم النهائي أو العملاء بأدائها، على التعرف على المشكلات البسيطة مثل أخطاء الهجاء أو المشكلات التجميلية، أو حتى عيوب شوستوبر (showstopper defect)، مثل عمليات انهيار البرمجيات [software crashes)؛ وذلك لأن المختبرين والمطورين يقومون بتحديد مثل تلك المشكلات مسبقاً، إصلاحها وعلاجها، وذلك خلال مراحل الفحص الأولي للوحدة (unit testing)، فحص التكامل (integration testing)، فحص النظام نفسه.  وتعطي نتائج تلك الاختبارات الثقة للعملاء والمستخدمين حيث أنها توضح لهم كيفية عمل النظام في عملية الإنتاج فيما بعد. هذا وقد تكون هناك كذلك متطلباتٍ عقديةٍ أو قانونيةٍ لقبول النظام.  يمثل اختبار قبول المستخدم كمياً (أو بصورةٍ أبسط «المدخل الكمي») عمليةً معكوسةً لاختبار قبول العمل (Business Acceptance Testing) والتي تستهدف توفير بديلٍ أفضل وأسرع لمرحلة اختبار قبول المستخدم التقليدية. ويتم تنفيذ عملية اختبار العمق (Depth-testing) في مقابل متطلبات العمل فقط عند نقاطٍ خاصةٍ مخططةٍ في التطبيق أو الخدمة محل الفحص والاختبار. فمن المفترض أن يكون هناك اعتمادٌ على كود توصيلٍ أفضلٍ للجودة من مرحلة التطوير/ البناء بالإضافة إلى أن الفهم الكامل لعملية العمل المناسبة لهو متطلبٌ رئيسيٌ. ونلاحظ أن تلك المنهجية - لو تم تنفيذها بأسلوبٍ صحيحٍ - تسفر عن تحولٍ سريعٍ ضد الخطة، والخاصة بعددٍ منخفضٍ ومقلصٍ من سيناريوهات الاختبارات والتي تعتبر أكثر تعقيداً وأوسع مجالاً في العرض من عملية اختبار قبول المستخدم التقليدية، كما أنها تمثل المرادف لمستوى الثقة الذي تم تحقيقه عبر نافذة التوصيل الأقصر، مما يسمح بوصول المنتجات أو التغيرات إلى السوق بصورةٍ أسرعٍ.  وهنا يعتمد مدخل اختبار قبول المستخدم الكمي على نموذجٍ «بوابيٍ» ثلاثي الأبعاد. وتتمثل الأفكار الرئيسية لذلك النموذج في:  وهنا تتصرف البوابات الأربع والتي تدعم وتقوي النموذج الثلاثي الأبعاد كحراس الجودة وتتضمن أفكار الاختبار المعاصرة مثل ما يلي:  و قد تم تحدسد ملامح المدخل الكمي من قِبَلِ طريقة «غوريلا» لاختبارات القبول والتي كانت نفسها استجابةً لمراحل الاختبار والتي أثبتت أنها باهظة التكاليف لتكون ثابتة للعديد من المشاريع الصغيرة أو المتوسطة.  اُسْتُخْدِمَ مصطلح «اختبار القبول» في منهجيات تطوير البرمجيات الذكية، وخاصةً البرمجيات المفرطة (Extreme Programming)، ليشير بذلك إلى الفحص الوظيفي لرواية المستخدم من قِبَلِ فريق تطوير البرمجيات خلال مرحلة التنفيذ.  ويُحدد المستهلك السيناريوهات اللازمة لاختبار موعد تنفيذ رواية المستخدم بصورةٍ صحيحةٍ. حيث قد يكون للرواية واحداً أو أكثر من اختبارات القبول، مهما كان ما يستلزمه الأمر لضمان عمل الوظيفية. وتعتبر اختبارات القبول اختبارات نظام الصندوق الأسود. ويمثل كل اختبار قبول بعض النتائج المتوقعة من النظام. مما يجعل العملاء مسؤولين عن إثبات صحة اختبارات القبول ومراجعة نتائج الاختبارات لتقرير أية الاختبارات الفاشلة تتمتع بأعلى أولويةٍ. هذا وتُستخدم اختبارات القبول كاختبارات انحدار قبيل إطلاق عملية الإنتاج. وهنا لا تعتبر رواية المستخدم كاملةً حتى تجتاز اختباؤرات القبول الخاصة بها. وهذا يعني أن اختبارات القبول الجديدة يجب أن يتم بنائها لكل تكرارٍ (iteration) أو سيقوم فريق تطوير بالإقرار بفشل عملية التقدم.  تتضمن الأنماط النموذجية لاختبارات القبول ما يلي:-  اختبار قبول المستخدم (User acceptance testing)  اختبار القبول التنفيذية (Operational Acceptance Testing)  اختبار قبول التعاقدات والتشريعات (Contract and regulation acceptance testing)  اختبارات ألفا وبيتا (Alpha and beta testing)   [1- 4] مراحل بيئة التطوير التقليدية في مشاريع التطوير متوسطة الحجم.