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

لماذا يهم

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

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

ما الذي يفحصه التحقق من صلاحية المتطلبات

يقارن التحقق من الصلاحية المتطلبَ باحتياجات الناس الذين يخدمهم. هؤلاء هم أصحاب المصلحة (Stakeholders): المستخدمون النهائيون، والعميل أو مالك العمل الذي طلب التغيير، وكل من يمسّ التغيير عمله، مثل الدعم الفني والعمليات والمالية والامتثال. وكثير مما يعرفونه غير مكتوب في أي مكان، لذا يعني التحقق من الصلاحية دائماً أن تسألهم، وأن تراقبهم وهم يعملون حيث أمكن.

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

كيف يختلف عن مراجعة المتطلبات

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

وكلاهما في الغالب اختبار ساكن (Static Testing)، إذ لا يُشغَّل فيه شيء، ويذكر منهج CTFL v4.0 أن الاختبار الساكن يخدم التحقق والتحقق من الصلاحية معاً. فالجولة التفقدية مع المستخدمين المستقبليين مراجعةٌ أيضاً. وما يجعل النشاط تحققاً من الصلاحية هو ما يُقارَن به المتطلب، لا شكل الاجتماع.

ويكشف كلٌّ منهما مشكلات مختلفة، فلا يغني أحدهما عن الآخر. قد يجتاز المتطلب المراجعة ويخفق في التحقق من الصلاحية، مثل قاعدة إلغاء الطلب: مكتوب جيداً وقابل للاختبار وخاطئ. وقد يرضي أصحاب المصلحة في اجتماع ويخفق في المراجعة، لأن «الإلغاء السريع» بدا مقبولاً حين قيل لكنه بلا معنى قابل للاختبار.

• المراجعة تسأل «هل كُتب بطريقة صحيحة؟»، والتحقق من الصلاحية يسأل «هل هو الحاجة الصحيحة؟».
• يمكن أن يجري المراجعةَ فريقُ التطوير نفسه، مثل مالك المنتج ومطور ومختبِر معهم قائمة فحص؛ أما التحقق من الصلاحية فيحتاج أصحاب الحاجة أنفسهم أو أقرب من يمثّلهم.
• ملاحظة المراجعة تعود إلى المؤلف تعليقاً للتصحيح؛ أما ملاحظة التحقق من الصلاحية فقرار لمالك المنتج: تأكيد المتطلب أو تغييره أو إضافة متطلب جديد.
• بعض الفرق وبعض كتب هندسة المتطلبات تستخدم «التحقق من صلاحية المتطلبات» للفحص الكامل لوثيقة المتطلبات، بما فيه الاتساق والاكتمال. فإذا سمعت المصطلح فاسأل أيّ السؤالين هو المقصود.

أربع تقنيات للتحقق من الصلاحية

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

• مراجعة أصحاب المصلحة (Stakeholder Review): يُقرأ المتطلب مع أصحاب الحاجة، لا من فريق التطوير وحده. اسألهم عن عملهم لا عن الصياغة: «احكِ لي خطوةً بخطوة آخر مرة قمت فيها بهذا»، «ماذا يحدث في أكثر أيامك ازدحاماً؟»، «من غيرك يتأثر؟». والوثائق الطويلة المرسلة للاعتماد تُعتمد غالباً دون أن تُقرأ، فراجع بضع قصص في كل مرة، وبالحوار المباشر حيث أمكن.
• الجولة التفقدية (Walkthrough): يقود المؤلف، وهو عادةً مالك المنتج أو محلل الأعمال، أصحابَ المصلحة عبر المتطلب كأنه قصة: «عميل يطلب الساعة ⁦21:30⁩ مساء الخميس، ثم…». وفي CTFL v4.0 الجولة التفقدية هي نوع المراجعة الذي يقوده المؤلف، ومن أهدافها الوصول إلى توافق وتعليم المشاركين إلى جانب اكتشاف الشذوذات.
• النموذج الأولي (Prototype): رسم على الورق أو مخطط هيكلي (Wireframe) أو نموذج قابل للنقر يجرّب عليه أصحاب المصلحة مهامّ حقيقية بينما تراقب أين يترددون. يكشف احتياجات لا يستطيع المستخدمون وصفها مسبقاً، لكنه يُظهر السطح فقط لا القواعد التي خلفه، وقد يجعل النموذجُ المصقول الناسَ يظنون أن المنتج شبه جاهز.
• اختبارات القبول في صورة أمثلة: حالات ملموسة لكلٍّ منها مُدخل ونتيجة متوقعة، تُكتب قبل البرمجة ويؤكدها صاحب المصلحة: «طلب الساعة ⁦15:00⁩ لموعد ⁦17:00⁩: مقبول. هل هذا صحيح؟». وهذه فكرة التطوير المقاد باختبارات القبول (ATDD) في CTFL v4.0. والخلاف على نتيجة متوقعة واحدة يكشف قاعدة خاطئة أو ناقصة، والأمثلة المتفق عليها تُنفَّذ لاحقاً اختباراتِ قبول.

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

مثال تطبيقي: التحقق من صلاحية قاعدة «اطلب واستلم»

تضيف سلسلة متاجر بقالة خدمة «اطلب واستلم من الفرع» (Click and Collect). ينص المتطلب REQ-17 على: «يختار العميل موعد استلام مدته ساعة بين ⁦10:00⁩ و⁦22:00⁩ في أحد الأيام الثلاثة القادمة. يجب تقديم الطلب قبل بداية موعده بساعتين على الأقل. يقبل كل موعد ⁦20⁩ طلباً كحد أقصى». اجتاز المتطلب المراجعة: كل رقم صريح وكل قاعدة قابلة للاختبار. ثم يتحقق مالك المنتج من صلاحيته مع الناس الذين يغيّر عملهم، ويحضر المختبِر كل جلسة.

استخدمت كل جلسة تقنية مختلفة، ووجدت كلٌّ منها شيئاً ما كانت أي قائمة فحص للمراجعة لتجده، لأن REQ-17 كان واضحاً ومتسقاً وقابلاً للاختبار:

• مراجعة أصحاب المصلحة مع مديرَي فرعين: ساعات العمل تختلف من فرع لآخر وتتغير في رمضان، فالمواعيد الثابتة من ⁦10:00⁩ إلى ⁦22:00⁩ ستعرض أوقاتاً تكون فيها بعض الفروع مغلقة. يجب أن تتبع المواعيد ساعات عمل كل فرع.
• جولة تفقدية مع موظفي تجهيز الطلبات: المرور على مساء خميس مزدحم يُظهر أن ⁦20⁩ طلباً صغيراً و⁦20⁩ طلباً من ⁦60⁩ صنفاً يستغرق تجهيزها أوقاتاً مختلفة جداً. فالحد الحقيقي هو طاقة التجهيز، لا عدد الطلبات.
• جلسة نموذج أولي مع خمسة عملاء: في نموذج قابل للنقر اختار ثلاثة منهم موعداً قبل أن ينتبهوا إلى أنه لفرع غير الذي قصدوه. يجب اختيار الفرع، وإبقاؤه ظاهراً، قبل عرض المواعيد.
• أمثلة قبول مع مالك العمل: تأكّد المثال «طلب الساعة ⁦15:00⁩ لموعد ⁦17:00⁩: مقبول». أما «طلب الساعة ⁦07:30⁩ لموعد ⁦10:00⁩: مقبول» فلم يتأكد: التجهيز يبدأ الساعة ⁦09:00⁩، فلن يحظى هذا الطلب إلا بساعة تجهيز واحدة. فالساعتان تعنيان وقت تجهيز، وهي قاعدة لم يكتبها أحد.

سجل التحقق من صلاحية REQ-17
V1  مراجعة أصحاب المصلحة · مديرو الفروع
    قاعدة خاطئة: المواعيد تتجاهل ساعات عمل كل فرع.
V2  جولة تفقدية · موظفو تجهيز الطلبات
    قاعدة خاطئة: الحد يعدّ الطلبات، بينما يعتمد وقت التجهيز على عدد الأصناف.
V3  نموذج أولي · 5 عملاء
    حاجة ناقصة: 3 من 5 اختاروا موعداً قبل الانتباه إلى الفرع.
V4  أمثلة قبول · مالك العمل
    قاعدة ناقصة: «ساعتان» تعني وقت تجهيز، لا مجرد فارق في التوقيت.

مالك المنتج: V1 وV3 وV4 تغيّر REQ-17 قبل السبرنت. وتصبح V2 قصة مستقلة
بعد أن تقدّر العمليات أوقات التجهيز. يعود REQ-17 v2 إلى المراجعة، ثم
تُؤكَّد V1 وV3 وV4 مع من طرحوها.

جرّبها: المتطلبات ← سيناريوهات اختبار

أسئلة شائعة

المراجع

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• ISTQB GlossaryISTQBالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
• Certified Tester Acceptance Testing (CT-AcT)ISTQB · 2019منهج ISTQB التخصصي لاختبار القبول: اختبار قبول المستخدم والقبول التعاقدي والتنظيمي، واختبارا ألفا وبيتا، وتعاون المختبِرين مع مالكي المنتج ومحللي الأعمال.
• The 2020 Scrum GuideKen Schwaber and Jeff Sutherland · 2020تعريف Scrum: مسؤولياته وأحداثه ومخرجاته، بما فيها تعريف الإنجاز (Definition of Done) الذي يساعد الاختبار على تحقيقه.