مستويات الاختبار
مستويات الاختبار
ليست جميع العيوب متشابهة، وليست جميع الاختبارات تكتشفها في المرحلة ذاتها. خطأ في دالة حسابية واحدة يختلف كلياً عن خطأ لا يظهر إلا حين تتواصل ثلاثة أنظمة فرعية متكاملة مع بعضها — أو عن تباين بين ما توقعه المستخدمون وما بناه المطورون. مستويات الاختبار هي الإجابة المنظمة على هذه الحقيقة: كل مستوى يستهدف نطاقاً محدداً من النظام، ويستخدم أساليب معينة، ويتملّكه فريق بعينه. بدءاً من أصغر وحدة صعوداً، فإن المستويات الأربعة المعترف بها عالمياً هي: اختبار الوحدات، واختبار التكامل، واختبار النظام، واختبار القبول.
إن فهم موقع كل مستوى — ومن المسؤول عنه — من أكثر المعارف العملية قيمةً لمحلل الأنظمة. حين يسأل أحد أصحاب المصلحة "كيف نعرف أن النظام صحيح؟" يجب أن يكون المحلل قادراً على تقديم إجابة منظمة تشمل المستويات الأربعة.
نموذج V: التحليل والاختبار كصورتين متقابلتين
الطريقة الكلاسيكية لتصوير مستويات الاختبار هي نموذج V. يهبط الذراع الأيسر عبر مراحل التحليل والتصميم؛ ويصعد الذراع الأيمن عبر مراحل الاختبار المقابلة. كل مستوى اختبار يُصادق مباشرةً على المرحلة التي تعكسه: اختبارات الوحدات تُصادق على التصميم التفصيلي، واختبارات التكامل تُصادق على التصميم المعماري، واختبارات النظام تُصادق على مواصفة متطلبات النظام (SRS)، واختبارات القبول تُصادق على متطلبات العمل الأصلية.
المستوى الأول — اختبار الوحدات
النطاق: دالة واحدة، أو وحدة، أو فئة، أو وحدة نمطية — أصغر قطعة كود يمكن اختبارها بشكل مستقل.
المالك: المطوّر الذي كتب الكود. تُكتب اختبارات الوحدات من قِبَل المطورين، في أغلب الأحيان قبل كود الإنتاج أو بالتوازي معه (كما في التطوير القائم على الاختبار — TDD).
ما تتحقق منه: هل تُعيد هذه الدالة النتيجة الصحيحة للمدخلات الصالحة؟ هل تتعامل مع المدخلات غير الصالحة بشكل رشيد؟ هل تستوفي المنطق المحدد في التصميم التفصيلي؟
مثال تجاري — متجر إلكتروني: يحتوي محرك التسعير على دالة applyDiscount(price, couponCode). يتحقق اختبار الوحدة من: هل يُنتج كوبون خصم 10% السعر المخفَّض الصحيح؟ هل يعيد الكوبون المنتهي صلاحيته السعر الأصلي؟ هل يرمي كود كوبون null خطأً محكوماً بدلاً من تعطّل التطبيق؟ هذه الاختبارات تعمل في ميلي ثوانٍ، ولا تحتاج قاعدة بيانات، وتُقدم للمطور تغذية راجعة فورية.
المستوى الثاني — اختبار التكامل
النطاق: مكونان أو أكثر يعملان معاً — وحدة نمطية تستدعي قاعدة بيانات، أو خدمة تستهلك واجهة برمجية (API)، أو بوابة دفع تتفاعل مع نظام الطلبات.
المالك: عادةً مزيج من المطورين المتميزين ومهندسي ضمان الجودة (QA). يمتد اختبار التكامل عبر حدود الفرق، لذا التنسيق أمر بالغ الأهمية.
ما يتحقق منه: هل تتطابق الواجهات بين المكونات؟ هل تتدفق البيانات بشكل صحيح عبر حدود الوحدات النمطية؟ هل تُعالَج الموارد المشتركة (قواعد البيانات، قوائم الانتظار، الواجهات الخارجية) بشكل صحيح تحت الحِمل المشترك؟
مثال تجاري — متجر إلكتروني: بعد نجاح اختبارات الوحدات الفردية، يتحقق اختبار التكامل من أن OrderService يكتب الطلب المؤكَّد في قاعدة البيانات بشكل صحيح، ويُطلق في الوقت ذاته رسالةً إلى NotificationService (الذي يرسل بريد التأكيد)، ويُنقص كمية المنتج الصحيح في وحدة المخزون. كل وحدة نجحت بمفردها؛ اختبار التكامل يتحقق من أنها تعمل معاً دون فقدان بيانات أو تعارضات.
من أشيع حالات فشل التكامل عدم تطابق الواجهات: خدمة الدفع تتوقع مبلغاً بالسنتات (عدد صحيح) لكن خدمة الطلبات ترسل عشرياً بالدولارات. كلاهما ينجح في اختبارات الوحدة بمعزل؛ وفقط اختبار التكامل يكشف التناقض.
المستوى الثالث — اختبار النظام
النطاق: النظام المتكامل بالكامل، مُختبَراً كمنتج مكتمل مقابل مواصفة متطلبات النظام (SRS).
المالك: فريق QA أو اختبار مستقل، منفصل عن فريق التطوير. الاستقلالية مهمة هنا — المطوّر الذي افترض شيئاً بشأن متطلب ما سيفترض الافتراض ذاته حين يختبره.
ما يتحقق منه: هل يُحقق النظام الكامل كل متطلب وظيفي؟ هل يعمل ضمن حدود مقبولة (أداء، أمان، موثوقية)؟ هل يتصرف بشكل صحيح عبر جميع المنصات والمتصفحات المدعومة؟
مثال تجاري — شركة لوجستية: تنص SRS الخاصة بنظام التوزيع على "يجب أن يتمكن السائقون من تحديث حالة التسليم من جهاز محمول في غضون 3 ثوانٍ حتى عبر اتصال 3G". يُنشر النظام الكامل في بيئة تجريبية، وتُوصَّل أجهزة GPS حقيقية، ويُحاكَى 200 سائق يحدّثون الحالة في آنٍ واحد، ثم يُقاس زمن الاستجابة. اختبارات الوحدات والتكامل لا تجيب على هذا السؤال — وفقط الاختبار الكامل للنظام يستطيع ذلك.
يشمل اختبار النظام أيضاً السيناريوهات السلبية: ماذا يحدث لو انقطعت إشارة GPS في منتصف التحديث؟ ماذا لو حاول سائق تحديد الطرد كـ"مُسلَّم" قبل استلامه؟ تُستخلص هذه الحالات الحافة مباشرةً من متطلبات SRS ومن معرفة المحلل بالعمليات التجارية الواقعية.
المستوى الرابع — اختبار القبول (UAT)
النطاق: النظام من منظور المستخدم النهائي والأعمال، مُصادَق عليه مقابل متطلبات العمل الأصلية وحالات الاستخدام الواقعية.
المالك: جهة العمل — المستخدمون الفعليون، وأصحاب المنتج، ومحلل الأنظمة. دور المحلل هنا محوري: فقد سهّل عملية استيفاء المتطلبات، والآن يُسهّل التحقق من استيفائها.
ما يتحقق منه: هل يؤدي النظام ما تحتاجه الأعمال فعلاً؟ هل هو قابل للاستخدام من قِبَل أشخاص حقيقيين في سير عمل حقيقي؟ هل يمتثل للالتزامات التنظيمية أو التعاقدية؟ هل الأعمال جاهزة للتوقيع على الاستلام والانطلاق؟
مثال تجاري — شركة لوجستية: بعد أن يُقرّ فريق QA نتائج اختبار النظام، يقوم منسقو التوزيع الفعليون ومديرو المستودعات بتشغيل النظام باستخدام مهامهم اليومية الحقيقية — حجز التسليمات، وإيفاد السائقين، وتحديث قوائم الشحن، وإنشاء تقارير نهاية اليوم. هم لا يتبعون سيناريو حالات اختبار تقنية؛ بل يؤدون عملهم الفعلي ويُبلغون عن أي فجوة بين ما توقعوه وما يختبرونه. نظام يجتاز جميع اختبارات QA قد يفشل في UAT إذا كانت واجهته بطيئة جداً لعامل مستودع يدير 400 طرد في كل وردية.
ملخص جانب بجانب
لماذا تهم الملكية المحلل؟
لكل مستوى اختبار مالك طبيعي، لكن المحلل مسؤول عن ضمان حدوث المستويات الأربعة جميعاً وأنها قابلة للتتبع وصولاً إلى المتطلبات الأصلية. الاستخلاص العملي من ذلك:
- عند إنشاء مصفوفة تتبع المتطلبات (RTM) (تُغطَّى في الدرس السادس)، يجب أن يتتبع كل متطلب إلى الأمام بحالة اختبار على مستوى النظام على الأقل وسيناريو اختبار قبول واحد.
- خلال تخطيط المشروع، يجب على المحلل التأكد من أن الفريق خصص وقتاً وميزانيةً للمستويات الأربعة — المشاريع التي تُخصص ميزانية لاختبار الوحدات وتتخطى اختبار النظام الرسمي كثيراً ما تكتشف فجوات التكامل والامتثال لـ SRS بعد الإطلاق فحسب.
- عند اكتشاف خلل، يجب على المحلل أن يتساءل: "في أي مستوى كان يجب اكتشاف هذا؟" خطأ في الإنتاج كان يجب اكتشافه في اختبار الوحدات يشير إلى ثغرة في ممارسات فريق التطوير. خلل يُكتشف فقط في UAT وينبثق من متطلب مفهوم بشكل خاطئ يشير إلى ثغرة في عملية التحليل.