التحقق مقابل الصحة — بناء النظام الصحيح أم بناؤه بالطريقة الصحيحة

التحقق مقابل الصحة — بناء النظام الصحيح أم بناؤه بالطريقة الصحيحة

يصطدم كل محلل في نهاية المطاف بمشروع يجتاز جميع الاختبارات التقنية ثم يُخيّب ظن مستخدميه. نظام حجز مواعيد عيادة يحجز المواعيد بكفاءة مثالية — لكنه يحجزها بتوقيت UTC بينما يعمل جميع الأطباء بالتوقيت المحلي. صفحة دفع في متجر إلكتروني تعالج المدفوعات بلا أخطاء — لكنها تُخفي تكلفة الشحن حتى الشاشة الأخيرة فتسبب في التخلي عن 40% من سلات التسوق. النظام نفّذ بالضبط ما بنته الفرقة التقنية. لكنه لم ينفّذ ما تحتاجه المنظمة فعلاً.

هذه الهوّة بين "بُني بطريقة صحيحة" و"بُني الشيء الصحيح" هي محور مفهومين جوهريين في الجودة: التحقق (Verification) والصحة (Validation). إتقان الفارق بينهما شرط أساسي لتصميم اختبارات ذات معنى، وكتابة معايير قبول مفيدة، وكسب ثقة المطورين وأصحاب المصلحة معاً.

التعريفات الجوهرية

التحقق (Verification) يسأل: "هل نبني النظام بالطريقة الصحيحة؟" يتحقق من أن المنتج يتوافق مع مواصفاته — أن ما صُمّم هو ما بُني فعلاً. أنشطة التحقق تقارن المنتج بوثيقة أو معيار أو نموذج، ويمكن إجراؤها دون إشراك المستخدمين النهائيين إطلاقاً.

الصحة (Validation) يسأل: "هل نبني النظام الصحيح؟" يتحقق من أن المنتج يحل الإشكالية الواقعية ويلبي احتياجات أصحاب المصلحة. أنشطة الصحة تستلزم إشراك مستخدمين حقيقيين أو ممثلين عن الأعمال. يمكن للمنتج أن يجتاز جميع اختبارات التحقق ويفشل في الصحة.

تذكّر بوابة تتبع الطرود التي ذكرناها سابقاً في الدورة. كان بإمكان الفريق أن يتحقق بصرامة من أن كل شاشة تطابق التصاميم المعتمدة، وكل استدعاء API يعيد JSON صحيحاً، وكل كتابة في قاعدة البيانات مقسّمة ذرياً. تمرّ كل اختبارات التحقق. ثم تذهب البوابة إلى اختبار القبول — فيبلّغ موظفو المستودع فوراً عن عدم قدرتهم على مسح الباركود لأن حقل الإدخال يقبل الكتابة من لوحة المفاتيح فقط. النظام بُني بالطريقة الصحيحة. لكنه لم يُبنَ بالطريقة الصحيحة لهؤلاء المستخدمين. الصحة تكتشف ما لا يستطيع التحقق اكتشافه.

نموذج V: ربط كل نشاط بناء بنشاط اختبار مقابل

نموذج V (المعروف أيضاً بنموذج التحقق والصحة) هو الإطار المرجعي لفهم كيفية تناظر مستويات الاختبار مع مستويات التطوير. يمثّل الذراع الأيسر للـ V أنشطة التحليل والتصميم — تحليل المتطلبات، وتصميم النظام، والتصميم التفصيلي، والبرمجة. يمثّل الذراع الأيمن أنشطة الاختبار — اختبار الوحدة، واختبار التكامل، واختبار النظام، واختبار القبول. لكل مستوى في الذراع الأيسر مستوى اختبار مقابل في الذراع الأيمن. والأسهم التي تعبر الـ V تمثّل علاقة التحقق (مواصفة الذراع الأيسر) والصحة (تأكيد الذراع الأيمن).

قراءة نموذج V

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

التحقق في التطبيق العملي

لا تستلزم أنشطة التحقق وجود نظام قيد التشغيل. من أشيع تقنيات التحقق:

• مراجعات المتطلبات — جلسات عمل منظمة لاستعراض وثيقة SRS مع المؤلف والزملاء ومحلل ضمان الجودة، بهدف رصد الغموض والتناقضات والقيود المفقودة قبل بدء التطوير.
• مراجعات التصميم الرسمية — فحص وثائق التصميم المعماري أو التفصيلي مقابل المتطلبات التي يُفترض أن تلبّيها.
• مراجعات الكود — التحقق من أن المنطق المُطبَّق يتوافق مع التصميم المعتمد ومعايير البرمجة.
• التحليل الساكن — أدوات آلية (linters، فاحصو الأنواع، ماسحو الأمن) تتحقق من خصائص الكود دون تنفيذه.

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

الصحة في التطبيق العملي

تستلزم الصحة سيناريوهات حقيقية وأشخاصاً حقيقيين. من أشيع أنشطة الصحة:

• اختبار قبول المستخدم (UAT) — يُنفّذ مستخدمون نهائيون ممثّلون سيناريوهات عمل في بيئة مرحلية ويؤكدون أن النظام يلبي احتياجاتهم.
• جلسات استعراض النماذج الأولية — عرض نماذج تفاعلية أو ورقية على أصحاب المصلحة في مرحلة مبكرة للتحقق من صواب اتجاه الحل المقترح.
• اختبار النسخة التجريبية (Beta) — إطلاق النظام لمجموعة محدودة من المستخدمين الحقيقيين لجمع الملاحظات قبل الإطلاق الكامل.
• الصحة في مواجهة العمليات التجارية — تشغيل النظام الجديد بالتوازي مع القديم للتحقق من أن المخرجات تتطابق مع ما كانت المنظمة تُنتجه سابقاً أو تتجاوزه.

مثال عملي: نظام حجز مواعيد العيادة

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

• التحقق (اختبارات الوحدة): تمنع وحدة الحجز بنجاح الحجوزات المزدوجة لنفس الطبيب في فترات زمنية متداخلة — يطابق مواصفة التصميم التفصيلي.
• التحقق (اختبارات التكامل): تتلقى خدمة تذكيرات الرسائل النصية بيانات المواعيد بشكل صحيح من محرك الحجز — يطابق مواصفة الواجهة.
• التحقق (اختبارات النظام): يستطيع المريض إتمام عملية الحجز الكاملة من البداية للنهاية بلا أخطاء — يطابق وثيقة متطلبات النظام.
• الصحة (UAT): يحاول موظفو الاستقبال الفعليون والمرضى تنفيذ سيناريوهات الحجز النموذجية. يكتشف موظفو الاستقبال أن عرض "الفترات المتاحة" لا يُبيّن ما إذا كان الطبيب في العيادة الرئيسية أم في فرع مساعد — ثغرة في المتطلبات الأصلية لم يكن أي اختبار تقني ليكتشفها.

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

خلاصة

• التحقق (Verification) يؤكد أن المنتج يتوافق مع مواصفاته — "بناء الشيء بالطريقة الصحيحة".
• الصحة (Validation) يؤكد أن المنتج يلبي الاحتياجات الحقيقية للمستخدمين والمنظمة — "بناء الشيء الصحيح".
• يزاوج نموذج V بين كل مستوى تطوير ومستوى اختبار مناظر، من التصميم التفصيلي/اختبار الوحدة وصولاً إلى متطلبات الأعمال/اختبار القبول.
• أنشطة التحقق (المراجعات، الفحوصات، التحليل الساكن) تُنجز دون تشغيل النظام ودون إشراك المستخدمين.
• أنشطة الصحة (UAT، جلسات استعراض النماذج، اختبار النسخة التجريبية) تستلزم مستخدمين حقيقيين وسيناريوهات عمل واقعية.
• بوصفك محللاً، أنت من يحدد معايير القبول جنباً إلى جنب مع المتطلبات — هذا هو إسهامك الأساسي في ضمان الجودة.