اختبار قبول

يُجرى اختبار القبول^[1] (بالإنجليزية: Acceptance testing)‏ في كلٍ من مجال الهندسة وأنظمتها الفرعية المختلفة بهدف تحديد ما إذا تمت تلبية متطلبات المواصفات المعيارية أو التعاقدات القانونية. فهي قد تتضمن كلٌ من اختبار كيميائي (بالإنجليزية: chemical test)‏، اختبار فيزيائي (بالإنجليزية: physical test)‏ أو حتى اختبارات الأداء (بالإنجليزية: performance test)‏.

وفي مجال هندسة الأنظمة، قد يتضمن اختبار القبول أداء اختبار الصندوق الأسود (بالإنجليزية: Black-box testing)‏ على نظامٍ (على سبيل المثال: جزء من برمجية، العديد من الأجزاء المصطنعة الآلية، أو دفعاتٍ من المنتجات الكيميائية قبيل تسليمها.^[2] وهو أيضاً معروف بأنه اختبار وظيفي (بالإنجليزية: 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)، فحص النظام نفسه.

وتعطي نتائج تلك الاختبارات الثقة للعملاء والمستخدمين حيث أنها توضح لهم كيفية عمل النظام في عملية الإنتاج فيما بعد. هذا وقد تكون هناك كذلك متطلباتٍ عقديةٍ أو قانونيةٍ لقبول النظام.

يمثل اختبار قبول المستخدم كمياً (أو بصورةٍ أبسط «المدخل الكمي») عمليةً معكوسةً لاختبار قبول العمل (Business Acceptance Testing) والتي تستهدف توفير بديلٍ أفضل وأسرع لمرحلة اختبار قبول المستخدم التقليدية.^{[بحاجة لمصدر]} ويتم تنفيذ عملية اختبار العمق (Depth-testing) في مقابل متطلبات العمل فقط عند نقاطٍ خاصةٍ مخططةٍ في التطبيق أو الخدمة محل الفحص والاختبار. فمن المفترض أن يكون هناك اعتمادٌ على كود توصيلٍ أفضلٍ للجودة من مرحلة التطوير/ البناء بالإضافة إلى أن الفهم الكامل لعملية العمل المناسبة لهو متطلبٌ رئيسيٌ. ونلاحظ أن تلك المنهجية - لو تم تنفيذها بأسلوبٍ صحيحٍ - تسفر عن تحولٍ سريعٍ ضد الخطة، والخاصة بعددٍ منخفضٍ ومقلصٍ من سيناريوهات الاختبارات والتي تعتبر أكثر تعقيداً وأوسع مجالاً في العرض من عملية اختبار قبول المستخدم التقليدية، كما أنها تمثل المرادف لمستوى الثقة الذي تم تحقيقه عبر نافذة التوصيل الأقصر، مما يسمح بوصول المنتجات أو التغيرات إلى السوق بصورةٍ أسرع.

وهنا يعتمد مدخل اختبار قبول المستخدم الكمي على نموذجٍ «بوابيٍ» ثلاثي الأبعاد. وتتمثل الأفكار الرئيسية لذلك النموذج في:

1. الاختبار الخطي (البعد الواحد)
2. الاختبار الرجعي (ثنائي الأبعاد)
3. الاختبار التكيفي (ثلاثي الأبعاد).

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

• فحوصات التوافق الداخلي (ICS)
• فحوصات الخدمات/ الأنظمة الرئيسية (MSC)
• الانحدار التفاعلي / الوقت الحقيقي (RTR).

وقد تم تحديد ملامح المدخل الكمي من قِبَلِ طريقة «غوريلا» لاختبارات القبول والتي كانت نفسها استجابةً لمراحل الاختبار والتي أثبتت أنها باهظة التكاليف لتكون ثابتة للعديد من المشاريع الصغيرة أو المتوسطة.

اُسْتُخْدِمَ مصطلح «اختبار القبول» في منهجيات تطوير البرمجيات الذكية، وخاصةً البرمجيات المفرطة (Extreme Programming)، ليشير بذلك إلى الفحص الوظيفي لرواية المستخدم من قِبَلِ فريق تطوير البرمجيات خلال مرحلة التنفيذ.

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

تتضمن الأنماط النموذجية لاختبارات القبول ما يلي:-

اختبار قبول المستخدم (User acceptance testing)

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

اختبار القبول التنفيذية (Operational Acceptance Testing)

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

اختبار قبول التعاقدات والتشريعات (Contract and regulation acceptance testing)

أما في اختبارات قبول التعاقدات، يتم اختبار وفحص النظام في مقابل معيار القبول كما تم توثيقه في التعاقد، وذلك قبيل قبول النظام. بينما يتم فحص النظام، في اختبارات قبول التشريعات، لضمان تلبيتها وتوافقها مع معايير السلامة، المعايير الحكومية والتشريعية القانونية.

اختبارات ألفا وبيتا (Alpha and beta testing)

تحدث اختبارات ألفا Alpha في مواقع المطورين، وتتضمن اختبار النظام التنفيذي من قِبَلِ فريق العمل الداخلي، وذلك قبيل إطلاقه إلى المستهلكين الخارجيين. أما اختبارات بيتا Beta فيتم إجرائها في مواقع المستهلكين، وتقوم بعملية الاختبار والفحص مجموعةٌ من المستهلكين الذين يستخدمون النظام في مواقعهم الخاصة، حيث يقوموا بتوفير تغذيةٍ مرتجعةٍ، وذلك كله قبيل إطلاق النظام للمستهلكين الآخرين. والاختبار الأخير (بيتا) غالباً ما يُطلق عليه اسم «الاختبار الحقلي الميداني» (field testing).

• بيئة التطوير (Development Environment) [1]
• بيئة اختبار التطوير (Development Testing Environment)
• اعتماد الجودة (بيئة الاختبار) (Quality Assurance) [2]
• اختبار تكامل ودمج التطوير (Development Integration Testing)
• اختبار تطوير النظام (Development System Testing)
• اختبار تكامل ودمج النظام (System Integration Testing)
• اختبار قبول المستخدم (User Acceptance Testing) [3]
• بيئة الإنتاج (Production Environment) [4]

[1- 4] مراحل بيئة التطوير التقليدية في مشاريع التطوير متوسطة الحجم.

• كونكورديون (بالإنجليزية: Concordion)‏
• فيتنيس (بالإنجليزية: FitNesse)‏
• فريمورك فور إنتيجريتد ورك (بالإنجليزية: Framework for Integrated Test)‏
• آي ماكروس (بالإنجليزية: iMacros)‏
• إتس نات (بالإنجليزية: ItsNat)‏، إطار عمل جافا أجاكس ويب لبناء قدرات فحص واختبار الويب الوظيفية القائمة على المخدم.
• رانوريكس (بالإنجليزية: Ranorex)‏
• سيلينيوم (بالإنجليزية: Selenium)‏
• تست أوتوميشن إف إكس (بالإنجليزية: Test Automation FX)‏
• واتير (بالإنجليزية: Watir)‏

• اختبار دراسي