التحقق مقابل التحقق من الصلاحية

لماذا يهم

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

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

سؤالان ومرجعان للمقارنة

يصف منهج ISTQB للمستوى التأسيسي (CTFL v4.0) الاختبار بأنه يشمل الأمرين: التحقق، أي فحص ما إذا كان النظام يستوفي المتطلبات المحددة، والتحقق من الصلاحية، أي فحص ما إذا كان يلبّي احتياجات المستخدمين وسائر أصحاب المصلحة في بيئة تشغيله. والفرق ليس في ما تفعله، بل في ما تقارن المنتج به.

• التحقق يقارن مُخرَج العمل بمواصفاته: الكود بالتصميم، والشاشة بمعايير قبولها، واستجابة الواجهة البرمجية بعقد الواجهة (API contract)، والمتطلب بصفات المتطلب الجيد (واضح ومتسق وقابل للاختبار).
• التحقق من الصلاحية يقارن المنتج باستخدامه المقصود: أهداف المستخدمين وطريقة عملهم وأجهزتهم وبياناتهم، والنتيجة التي يُفترض أن تحققها الميزة للعمل. وكثير من ذلك لا يُكتب أبداً، فعليك أن تسأل وتلاحظ.
• تستخدم بعض الفرق كلمة «validation» أيضاً لفحص المدخلات (نموذج يرفض بريداً إلكترونياً غير صالح) أو لفحص مخطط (schema) استجابة الواجهة البرمجية. هذه سلوكيات في البرنامج نفسه، واختبارها مقابل المواصفات تحقق.

لكلٍّ منهما صورة ساكنة وصورة ديناميكية

الاختبار الساكن (Static testing) يفحص مُخرَج العمل من دون تشغيل البرنامج: يراجعه أشخاص أو تحلله أدوات. والاختبار الديناميكي (Dynamic testing) يشغّل البرنامج. ويذكر منهج ISTQB أن الاختبار الساكن يمكن تطبيقه للتحقق وللتحقق من الصلاحية معاً. والاختبار الديناميكي يخدم الاثنين كذلك: فتشغيل اختبارات مشتقة من المتطلبات تحقق، أما اختبار القبول، الذي يصفه المنهج بأنه يركّز على التحقق من الصلاحية، فالأفضل أن يجريه المستخدمون المقصودون أنفسهم. لذا فالاختصار الشائع «التحقق مراجعات، والتحقق من الصلاحية تشغيل اختبارات» خاطئ.

• تحقق ساكن: مراجعة قصة مستخدم للتأكد من وضوح معاييرها وقابليتها للاختبار، ومقارنة عقد الواجهة البرمجية بالمتطلب، والتحليل الساكن للكود.
• تحقق ديناميكي: تنفيذ حالات اختبار مشتقة من معايير القبول.
• تحقق ساكن من الصلاحية: استعراض قصة أو رسومات للشاشات مع مستخدمي المنتج المستقبليين قبل كتابة أي كود.
• تحقق ديناميكي من الصلاحية: اختبار قبول المستخدم (UAT)، وتجربة تشغيلية أو إصدار تجريبي (beta) مع مستخدمين حقيقيين، وجلسات قابلية الاستخدام.

مثال تطبيقي: حجز موعد في عيادة

تريد عيادة أن يحجز المرضى مواعيدهم عبر موقعها. القصة: «بصفتي مريضاً، أريد حجز موعد عبر الإنترنت، كي لا أضطر إلى الاتصال بالاستقبال». معايير القبول: AC1، مواعيد مدتها ⁦15⁩ دقيقة من ⁦08:00⁩ إلى ⁦16:00⁩، من الأحد إلى الخميس؛ AC2، لا يحمل حساب المريض أكثر من موعد مستقبلي واحد؛ AC3، تُرسل رسالة SMS للتأكيد خلال دقيقة واحدة من الحجز. وإليك أربعة فحوص عليها بترتيب حدوثها: الفحصان الساكنان في جلسات تحسين قائمة العمل، والفحصان الديناميكيان بعد بناء الميزة.

• تحقق ساكن: في مراجعة القصة يسأل المختبِر: هل ⁦16:00⁩ آخر وقت لبدء موعد أم وقت الإغلاق؟ فيجيب مالك المنتج بأن آخر موعد يبدأ عند ⁦15:45⁩، ويُصحَّح AC1 قبل كتابة أي كود.
• تحقق ساكن من الصلاحية: يستعرض موظفو الاستقبال القصة ورسومات الشاشات، وينبّهون إلى أن أولياء الأمور يحجزون لأطفالهم من حساب واحد، فيمنع AC2 أحد الوالدين من الحجز لطفلين. فيصبح الحد موعداً مستقبلياً واحداً لكل مريض.
• تحقق ديناميكي: تحجز اختبارات المعايير المصحَّحة موعدَي ⁦08:00⁩ و⁦15:45⁩، وتتأكد من عدم عرض موعد عند ⁦16:00⁩، ومن رفض موعد مستقبلي ثانٍ للمريض نفسه مع قبول موعد لطفل ثانٍ من الحساب نفسه، وتقيس زمن وصول الرسالة. وكلها ناجحة.
• تحقق ديناميكي من الصلاحية: تُظهر تجربة تشغيلية لمدة أسبوع أن كثيراً من المرضى يختارون أول موعد متاح دون ذكر سبب الزيارة، مع أن تنظيف الأسنان يستغرق موعدين. استُوفي كل معيار، لكن المتطلب أغفل حاجة.

جرّبها: قصة المستخدم ← سيناريوهات اختبار جرّبها: المتطلبات ← حالات اختبار

لماذا تحتاج إلى الاثنين

التحقق من دون التحقق من الصلاحية يُنتج برنامجاً مطابقاً لمواصفات خاطئة أو ناقصة: فلم يكن لأي اختبار مشتق من المعايير AC1 إلى AC3 أن يفشل بسبب مشكلة مدة الزيارة. ويعدّ منهج ISTQB هذا الفخ أحد مبادئ الاختبار السبعة باسم «مغالطة غياب العيوب» (Absence-of-defects fallacy): فاختبار كل المتطلبات المحددة وإصلاح كل عيب يُكتشف قد ينتجان مع ذلك نظاماً لا يلبّي احتياجات المستخدمين، لذا يلزم التحقق من الصلاحية إلى جانب التحقق.

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

أسئلة شائعة

المراجع

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• ISTQB GlossaryISTQBالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.