استخلاص حالات الاختبار من المتطلبات
استخلاص حالات الاختبار من المتطلبات
الاختبار الذي لا يرتبط بمتطلب محدد هو اختبار بلا غاية. الاختبار القائم على المتطلبات هو منهجية تربط كل حالة اختبار بمتطلب موثق ومحدد، مما يضمن التحقق من النظام وفق النية التجارية التي أوجدته. يقف المحللون في قلب هذه المنهجية، لأنهم يملكون مسؤوليتين متكاملتين: كتابة المتطلبات الواضحة والتأكد من إمكانية اختبارها. إذا كان المتطلب لا يمكن اختباره، فهو لم يُكتب بشكل صحيح.
تسير هذه الدرس في الدورة الكاملة: قراءة المتطلب، واستخراج الشروط القابلة للاختبار منه، وبناء تلك الشروط في حالات اختبار رسمية، ثم قياس مدى تغطية مجموعة الاختبارات للنطاق الوظيفي.
ما الذي يجعل المتطلب قابلاً للاختبار؟
قبل استخلاص حالات الاختبار، يجب التأكد من أن المتطلب قابل للاختبار. يتسم المتطلب القابل للاختبار بأربع خصائص: محدد (سلوك واحد في كل جملة)، قابل للقياس (يحدد النتائج المتوقعة بمصطلحات يمكن رصدها)، قابل للتحقيق (ضمن حدود النظام)، ولا غموض فيه (لا مجال لتفسيرين). الاختصار التذكيري هو SMAA.
انظر إلى نسختين من المتطلب ذاته لنظام حجز عيادة:
- غير قابل للاختبار: "يجب أن يسمح النظام للمستخدمين بحجز المواعيد بسهولة."
- قابل للاختبار: "يجب أن يسمح النظام للمريض المسجّل بحجز موعد متاح في خلال 3 نقرات من الصفحة الرئيسية، ويؤكد الحجز عبر رسالة على الشاشة وبريد إلكتروني في غضون 30 ثانية."
النسخة الثانية تمنحك شروط اختبار صريحة: حالة التسجيل، وعدد النقرات، وتوفر الموعد، وقناة التأكيد، ووقت الاستجابة. كل شرط يصبح حالة اختبار محتملة.
من المتطلب إلى شروط الاختبار
الخطوة الأولى هي تحليل المتطلب: قراءته وسرد كل شرط مستقل يتضمنه. كل شرط يمثل حالة يجب أن يتعامل معها النظام بشكل صحيح.
خذ هذا المتطلب الوظيفي من نظام إدارة الطلبات عبر الإنترنت:
يُفضي تحليل REQ-027 إلى الشروط القابلة للاختبار التالية:
- حساب نشط + جميع الأصناف متوفرة ← قبول الطلب، تخفيض المخزون، إرسال البريد.
- حساب موقوف ← رفض الطلب وعرض رسالة خطأ.
- حساب نشط وصنف أو أكثر غير متوفر ← رفض الطلب مع تحديد الأصناف الناقصة.
- صحة احتساب الضريبة لكل فئة منتج.
- وصول بريد التأكيد في غضون 60 ثانية من الإرسال.
- تخفيض رصيد المخزون بمقدار الكمية المطلوبة بالضبط.
كل شرط من هذه الشروط يرتبط بحالة اختبار واحدة على الأقل. هذا الربط المباشر هو جوهر الاختبار القائم على المتطلبات.
بنية حالة الاختبار الرسمية
حالة الاختبار ليست مجرد إجراء — بل هي مواصفة كاملة لسيناريو اختبار واحد. تضم حالة الاختبار المُصاغة جيداً ستة حقول:
- معرّف حالة الاختبار — معرف فريد مثل
TC-027-01. - مرجع المتطلب — المتطلب (المتطلبات) التي تتحقق منها، مثل
REQ-027a, REQ-027d. - الشروط المسبقة — الحالة التي يجب أن يكون عليها النظام قبل تنفيذ الاختبار.
- خطوات الاختبار — الإجراءات المرقّمة التي ينفذها المختبِر.
- بيانات الاختبار — المدخلات المحددة كمعرّفات الحسابات والكميات وأكواد المنتجات.
- النتيجة المتوقعة — المخرج الملاحَظ الذي يُعتبر نجاحاً للاختبار.
تغطية المتطلبات الوظيفية
تغطية المتطلبات هي نسبة المتطلبات الوظيفية الموثقة التي تمتلك حالة اختبار ناجحة واحدة على الأقل. وهي مقياسك الرئيسي لاكتمال الاختبار على مستوى التحليل، وتُحسب كالتالي:
الهدف بنسبة 100% يعني اختبار كل سطر في مواصفاتك. في الواقع، تتطلب الأنظمة الحساسة للسلامة 100%؛ بينما تستهدف البرمجيات التجارية 90-95% للمتطلبات الوظيفية مع تأجيل حالات الحافة منخفضة الخطورة للإصدارات اللاحقة.
ربط المتطلبات بحالات الاختبار: مصفوفة عملية
في المشاريع متوسطة الحجم، يحتفظ المحللون بـجدول ربط المتطلبات بالاختبارات (مقدمة للمصفوفة الكاملة للتتبعية التي تُغطى في الدرس السادس). كل صف يمثل متطلباً، وكل عمود يمثل حالة اختبار، والعلامة تُظهر أن هذه الحالة تغطي ذلك المتطلب.
التعامل مع ثغرات التغطية
أي متطلب بدون حالة اختبار هو ثغرة في التغطية — نقطة عمياء محتملة في الإصدار. عند اكتشاف الثغرات، يعتمد الرد على مستوى الخطورة:
- ثغرة عالية الخطورة: اكتب حالات الاختبار المفقودة فوراً. أوقف الإصدار حتى تنجح.
- ثغرة متوسطة الخطورة: وثّق الثغرة كمخاطرة معروفة، عيّن مسؤولاً وحدد موعداً للتكرار القادم.
- متطلب مؤجل صراحةً: ضعه خارج نطاق الإصدار في مصفوفة التتبعية حتى يتضح للمراجعين أن القرار كان متعمداً لا غفلة.
حالات الاختبار الإيجابية والسلبية وحالات الحافة
لكل شرط اختبار، يجب تصميم ثلاث فئات على الأقل من حالات الاختبار:
- إيجابي (المسار السعيد): مدخلات صالحة، شروط مستوفاة، سير طبيعي — يجب أن ينجح النظام.
- سلبي (مسار الخطأ): مدخلات غير صالحة، انتهاكات حدودية، بيانات مفقودة — يجب أن يفشل النظام بأمان مع رسائل خطأ واضحة.
- حالات الحافة: قيم حدودية، حالات فارغة، أحمال قصوى، عمليات متزامنة — حيث يرتفع احتمال السلوك غير المتوقع للنظام.
بالنسبة لـ REQ-027 (إرسال الطلب)، تغطي المجموعة الكاملة العميل يضع طلباً صالحاً (إيجابي)، ويضع طلباً بكمية صفر لصنف ما (سلبي)، ويضع طلبين متزامنين يستنفدان معاً آخر وحدة في المخزون (حافة). كل من هذه الحالات يعود إلى شرط فرعي من المتطلب الأصلي.
قائمة تحقق المحلل قبل تسليم المتطلبات
قبل أن تغادر مواصفات المتطلبات مرحلة التحليل، مرّر كل متطلب وظيفي عبر هذه القائمة:
- هل يمكنني صياغة النتيجة المتوقعة بمصطلحات قابلة للرصد والقياس؟ إن لم يكن كذلك، أعد صياغة المتطلب.
- هل حددت كل شرط مستقل (بنود فرعية، قواعد عمل، مسارات خطأ) يتضمنه هذا المتطلب؟
- هل يمكن اختبار كل شرط بشكل مستقل بشرط مسبق محدد ومعيار نجاح/فشل واضح؟
- هل يوجد شرط اختبار واحد على الأقل للمسار الإيجابي، وآخر لمسار الخطأ، وثالث للقيمة الحدية؟
تلبية هذه القائمة قبل التسليم تقلل وقت تصميم الاختبار بشكل ملحوظ وتقضي فعلياً على التردد المحبط الذي يعود فيه المختبرون للمحللين يسألون عما يعنيه المتطلب. المتطلبات الواضحة هي في نهاية المطاف متطلبات مُختبَرة مسبقاً.