تطوير قائم على اختبار القبول

تُنشأ اختبارات القبول عند تحليل المتطلبات وقبل بدء البرمجة. ^{[ 1 ]} ويمكن تطويرها بشكل تعاوني بين طالب المتطلبات (مالك المنتج، محلل الأعمال، ممثل العميل، إلخ)، والمطور، والمختبر. يقوم المطورون بتنفيذ النظام باستخدام اختبارات القبول. توفر الاختبارات الفاشلة تغذية راجعة سريعة تفيد بعدم تلبية المتطلبات. تُحدد الاختبارات بمصطلحات مجال الأعمال، لتشكل لغة مشتركة بين العملاء والمطورين والمختبرين. ^{[ 10 ]} الاختبارات والمتطلبات مترابطة. ^{[ 11 ]} قد لا يُنفذ المتطلب الذي يفتقر إلى اختبار بشكل صحيح. الاختبار الذي لا يشير إلى متطلب ما هو اختبار غير ضروري. اختبار القبول الذي يُطور بعد بدء التنفيذ يمثل متطلبًا جديدًا. ^{[ 12 ]}

تُعدّ اختبارات القبول جزءًا من استراتيجية اختبار شاملة. وهي اختبارات موجهة نحو العميل/المستخدم، تُظهر الغرض التجاري للنظام. وبحسب استراتيجية الاختبار، يُمكن استخدامها مع أنواع أخرى من الاختبارات، مثل اختبارات الوحدة على مستوى أدنى ، ^{[ 13 ]} والاختبارات متعددة الوظائف، بما في ذلك اختبارات سهولة الاستخدام، ^{[ 14 ]} والاختبارات الاستكشافية، ^{[ 15 ]} واختبارات الخصائص (قابلية التوسع والأمان). ^{[ 16 ]}

عادةً ما تتبع اختبارات القبول هذا الشكل: ^{[ 1 ]}

معطى (إعداد)

حالة محددة للنظام

عند (التشغيل)

يحدث فعل أو حدث

ثم (التحقق)

لقد تغيرت حالة النظام أو تم إنتاج مخرجات

كما يمكن إضافة عبارات تبدأ بـ AND في أي من الأقسام أدناه (Given, When, Then).

بالنسبة لمتطلبات المثال، يمكن سرد الخطوات على النحو التالي:

بافتراض وجود كتاب لم تتم استعارته، ومستخدم مسجل في النظام، فعندما يستعير المستخدم كتابًا، يتم وضع علامة "مستعار" على الكتاب.

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

منح:

كتاب لم يتم استعارته

المستخدم المسجل في النظام

متى:

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

ثم:

تم وضع علامة "تم استعارة" على الكتاب.

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

• ماذا لو كان الكتاب مستعاراً بالفعل؟
• ماذا لو لم يكن الكتاب موجوداً؟
• ماذا لو لم يكن المستخدم مسجلاً في النظام؟
• هل هناك تاريخ محدد لإعادة الكتاب؟
• كم عدد الكتب التي يمكن للمستخدم استعارتها؟

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

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

السيناريو: التحقق من تطبيق قواعد العمل الخاصة بعملية الدفع.

منح:

كتاب تم استعارته

متى:

يستعير المستخدم كتابًا آخر

ثم:

حدث خطأ

إضافةً إلى اختبارات القبول الخاصة بالمتطلبات، يمكن استخدام اختبارات القبول على المشروع ككل. ^{[ 1 ]} على سبيل المثال، إذا كان هذا المتطلب جزءًا من مشروع استعارة الكتب من المكتبة، فيمكن إجراء اختبارات قبول للمشروع بأكمله. تُعرف هذه الاختبارات عادةً بأهداف SMART . ومن أمثلة هذه الاختبارات: "عندما يبدأ تشغيل نظام المكتبة الجديد، سيتمكن المستخدمون من استعارة الكتب وإعادتها أسرع بثلاث مرات مما يفعلونه اليوم".