اختبار قبول

بيئة الإنتاج (Production Environment) [4]

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

بيئة التطوير (Development Environment) [1]

بيئة اختبار التطوير (Development Testing Environment)

اعتماد الجودة (بيئة الاختبار) (Quality Assurance) [2]

• اختبار تكامل ودمج التطوير (Development Integration Testing)
• اختبار تطوير النظام (Development System Testing)
• اختبار تكامل ودمج النظام (System Integration Testing)
• اختبار قبول المستعمل (User Acceptance Testing) [3]

اختبار قبول المستخدم كمياً

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

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

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

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

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

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

آي ماكروس

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

• رانوريكس
• سيلينيوم
• تست أوتوميشن إف إكس
• واتير
• انظر كذلك
• اختبار دراسي

نظرة عامة

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

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

وعلى صعيد آخر، غالباً ما يقوم مستهلكو الأعمال التجارية والعملاء ببناء اختبارات/ معايير القبول (في تطوير البرمجيات الذكية ) وتتم صياغتها في سياق لغة نطاق الأعمال التجارية . حيث تعتبر تلك الاختبارات عالية المستوى لاختبار وفحص اكتمال رواية المستعمل (user story) أو الروايات التي تم «أداؤها» خلال أي فترة عَدْوٍ أو تكرارٍ. فقد تم بناء تلك الاختبارات مثالياً من خلال التعاون فيما بين مستهلكي وعملاء الأعمال التجارية المختلفة، محللي الأعمال، المختبرين، والمطورين، على الرغم من ذلك، فإن مستهلكوا الأعمال التجارية (ملاك المنتج) هم المالكون الأساسيون الأُوَل لهذه الاختبارات. وبسبب أن روايات المستعملين تجتاز معيار واختبار القبول، فإن أصحاب الأعمال قد يكونوا متأكدين حينئذٍ من حقيقة أن المطورين يتقدمون في الاتجاه الصحيح حول كيفية تخيل عمل البرنامج ومن ثم فمن الضروري أن تشتمل تلك الاختبارات على اختبارات منطق العمل فضلًا عن عناصر التحقق من فعالية واجهة المستعمل التفاعلية (لو لزمت الحاجة لذلك).

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

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

في هذا الإطار، ويقوم مصممو الاختبارات بإعداد اختباراتٍ رسميةٍ وتنويع مدىً واسعاً من مستويات الحدة. ونمطياً لا يجب أن يكون مصمم اختبارات قبول المستعمل منتج التكامل الرسمي ونظام حالات الاختبار (test case) لنفس النظام. وتلعب اختبارات قبول المستعمل آلية التحقق الأخيرة لوظيفة العمل المطلوب والوظيفية المناسبة للنظام، وذلك بمحاكاة نفس ظروف وشروط الاستخدام الواقعي الفعلي بالنيابة عن العميل الذي يقوم بالدفع أو المستهلك الخاص. حيث لو عمل البرنامج كما كان متوقعاً أو بدون نشأة مسائلٍ أخرى أثناء الاستخدام الطبيعي، فإن المرء يصبح حينئذٍ قادراٍ على استنتاج نفس مستوى الثبات في الإنتاج بعقلانيةٍ مبررةٍ.

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

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

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

العملية

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

في هذا الإطار، ويتمثل الهدف في منح الثقة في أن النظام الذي يتم تسليمه يُقابل ويلبي متطلبات العمل لكلٍ من الرعاة والمستعملين. هذا وقد تلعب مرحلة القبول كذلك دور بوابة الجودة الأخيرة، حيث قد يتم الكشف فيها عن أي عيوب جودةٍ لم تكن قد ظهرت أو استُشْعِرَت مسبقاً.

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

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

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

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

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

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

ومن جهة أخرى، اختبار قبول التعاقدات والتشريعات (Contract and regulation acceptance testing)

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

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

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

قائمة بيئات (الاختبار أو الفحص) من التطوير حتى الإنتاج

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

أنماط اختبارات القبول

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

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