الوحدة 2 · دورة حياة تطوير البرمجيات

النموذج الشلالي ونموذج V

بقلم فريق ضمان الجودة في متقن سوفت · · 19 دقيقة · مبتدئ

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

ونموذج V (V-model) تتابعي أيضاً، لكنه يُظهر الاختبار منذ البداية. ينزل ذراعه الأيسر عبر مواصفات تزداد تفصيلاً، وتقع البرمجة في رأسه السفلي، ويصعد ذراعه الأيمن عائداً عبر مستويات الاختبار. وتُقرن كل مواصفة بمستوى الاختبار الذي يفحص البرنامج مقابلها، فتُصمَّم اختبارات القبول للبوابة إلى جانب متطلبات العمل، قبل البرمجة بوقت طويل.

لماذا يهم

ما زالت مشاريع كثيرة تُدار بهذه الطريقة، خصوصاً حين يحدّد العقد النطاق، أو حين تطلب جهة تنظيمية أو العميل أدلة موثقة لكل مرحلة، أو حين يكون البرنامج جزءاً من مشروع أجهزة أو بنية تحتية. وفي مشروع كهذا عليك أن تعرف أي الوثائق هي أساس الاختبار (Test basis) لديك، ومتى تراجعها، وأي مستويات الاختبار تتولاها، وما معايير الدخول والخروج لمرحلتك.

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

مراحل النموذج الشلالي وموقع الاختبار فيها

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

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

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

نموذج V: لكل مستوى تطوير مستوى اختبار

يذكر CTFL v4.0 النموذج الشلالي ونموذج V كليهما مثالين على نماذج التطوير التتابعية. وما يضيفه نموذج V هو اقتران واحد لواحد: لكل مواصفة في طريق النزول مستوى اختبار في طريق الصعود يفحص البرنامج المبني مقابلها.

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

وبمصطلحات درس التحقق والتحقق من الصلاحية: اختبار البناء مقابل كل مواصفة هو التحقق (Verification)، واختبار القبول مقابل احتياجات المستخدمين الحقيقية هو التحقق من الصلاحية (Validation). ويقسم CTFL v4.0 التكامل أيضاً إلى اختبار تكامل المكوّنات واختبار تكامل الأنظمة، وهو ما يتناوله درس مستويات الاختبار.

  • متطلبات العمل والمستخدمين ↔ اختبار القبول (Acceptance testing): هل يستطيع المستخدمون المقصودون إنجاز عملهم بالنظام؟
  • مواصفة متطلبات النظام ↔ اختبار النظام (System testing): هل يتصرف النظام كاملاً كما هو محدد، بما في ذلك المتطلبات غير الوظيفية مثل الأداء؟
  • التصميم المعماري ↔ اختبار التكامل (Integration testing): هل تعمل المكوّنات والخدمات والأنظمة الخارجية معاً عبر واجهاتها؟
  • التصميم التفصيلي ↔ اختبار المكوّن (Component testing)، ويُسمّى غالباً اختبار الوحدة: هل يؤدي كل مكوّن ما يقوله تصميمه، معزولاً عن غيره؟
في نموذج V كل مواصفة على الذراع الأيسر هي أساس الاختبار لمستوى واحد: المتطلبات لاختبار القبول، ومواصفة النظام لاختبار النظام، والتصميم المعماري لاختبار التكامل، والتصميم التفصيلي لاختبار المكوّن. نموذج مفاهيمي
  1. الذراع الأيسر: المواصفة:
    1متطلبات العمل والمستخدمينما يحتاجه المستخدمون والعمل

    يغذّي: تُصمَّم منها اختبارات القبول

    الذراع الأيمن: مستوى الاختبار:
    اختبار القبوليُنفَّذ رابعاً وأخيراً: هل ينجز المستخدمون عملهم؟
  2. الذراع الأيسر: المواصفة:
    2مواصفة متطلبات النظامالنظام كاملاً، ومعه المتطلبات غير الوظيفية

    يغذّي: تُصمَّم منها اختبارات النظام

    الذراع الأيمن: مستوى الاختبار:
    اختبار النظاميُنفَّذ ثالثاً: النظام كاملاً مقابل مواصفته
  3. الذراع الأيسر: المواصفة:
    3التصميم المعماريالمكوّنات والواجهات بينها

    يغذّي: تُصمَّم منه اختبارات التكامل

    الذراع الأيمن: مستوى الاختبار:
    اختبار التكامليُنفَّذ ثانياً: الواجهات والتفاعلات
  4. الذراع الأيسر: المواصفة:
    4التصميم التفصيليما بداخل كل مكوّن

    يغذّي: تُصمَّم منه اختبارات المكوّن

    الذراع الأيمن: مستوى الاختبار:
    اختبار المكوّنيُنفَّذ أولاً، بعد البرمجة مباشرةً

بعد ذلك:تقع البرمجة في رأس حرف V؛ ثم يصعد التنفيذ الذراع الأيمن من اختبار المكوّن عائداً إلى اختبار القبول.

نموذج مفاهيمي: تختلف أسماء الوثائق بين المؤسسات، ويقسم CTFL v4.0 التكامل إلى اختبار تكامل المكوّنات واختبار تكامل الأنظمة.

مثال تطبيقي: نظام حجز مواعيد العيادات الخارجية

تتعاقد مجموعة عيادات مع مورّد لبناء نظام لحجز مواعيد العيادات الخارجية بسعر ثابت، مع وثيقة معتمدة لكل مرحلة. يتبع المشروع نموذج V، وينضم المختبِر في مرحلة المتطلبات لا بعد البرمجة.

ومع اعتماد كل وثيقة، يستخرج المختبِر اختبارات المستوى المقابل لها ويسجّل الروابط، فيكون لكل متطلب اختبار، ولكل اختبار متطلب يعود إليه. وقد كشف اثنان من البنود الأربعة أدناه ثغرة قبل وجود أي كود.

  • ⁦BR-2⁩ «يستطيع المريض الحجز عبر الإنترنت ويتلقى تذكيراً» ← اختبار القبول ⁦AT-2⁩: مرضى من مجموعة تجريبية يحجزون مواعيد حقيقية من هواتفهم، ويرى موظفو الاستقبال الحجوزات في قائمتهم اليومية. وأثارت كتابته سؤالاً مفتوحاً: إذا حجز مريض لأحد أفراد أسرته، فإلى هاتف مَن يُرسَل التذكير؟
  • ⁦SR-14⁩ «لا يحجز الموعد الواحد إلا مريض واحد» ← اختبار النظام ⁦ST-14⁩: جلستان تحجزان الموعد نفسه في اللحظة نفسها؛ فينجح حجز واحد، ويرى الآخر رسالة «لم يعد الموعد متاحاً».
  • ⁦AD-3⁩ «تُرسَل التذكيرات عبر بوابة رسائل نصية (SMS) خارجية» ← اختبار التكامل ⁦IT-3⁩: عند تعطّل البوابة يجب أن يُحفظ الحجز رغم ذلك. ولم يحدد التصميم مصير التذكير، فسجّل المختبِر عيباً في التصميم قبل البرمجة.
  • ⁦DD-9⁩ «تُرجع canCancel() القيمة true ما دام الموعد يبعد أكثر من ⁦24⁩ ساعة» ← اختبارات المكوّن ⁦CT-9⁩ التي يكتبها المطور: قبل الموعد بـ⁦24⁩ ساعة ودقيقة، وبـ⁦24⁩ ساعة تماماً، وبـ⁦23⁩ ساعة و⁦59⁩ دقيقة، والنتائج المتوقعة true ثم false ثم false.
Traceability: outpatient booking system (V-model)

Left arm (approved first)          Right arm (executed later)   Tests
BR-2   business requirement   <->  acceptance testing           AT-2
SR-14  system requirement     <->  system testing               ST-14.1  ST-14.2
AD-3   architectural design   <->  integration testing          IT-3.1   IT-3.2
DD-9   detailed design        <->  component testing            CT-9.1 .. CT-9.3

Designed:  AT -> ST -> IT -> CT   (as each document is approved)
Executed:  CT -> IT -> ST -> AT   (after coding, bottom-up)

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

نقاط القوة والمخاطر من منظور ضمان الجودة

لا يُعدّ أيّ من النموذجين جيداً أو سيئاً في ذاته: فكلٌّ منهما يناسب سياقات معيّنة ويجلب مخاطر متوقعة للاختبار.

  • نقطة قوة: أساس اختبار مستقر ومعتمد. تُتتبَّع الاختبارات إلى المتطلبات بوضوح، ويسهل إثبات التغطية للعميل أو للمدقق.
  • نقطة قوة: بوابات واضحة. معايير الدخول والخروج وخطة الاختبار الرسمية وتقرير إتمام الاختبار تنسجم مع المراحل بطبيعتها؛ ويشير CTFL v4.0 إلى أن معايير الخروج لمستوى اختبار ما تكون في النماذج التتابعية غالباً جزءاً من معايير الدخول للمستوى التالي.
  • نقطة قوة في نموذج V: التصميم المبكر للاختبارات يكشف الغموض والنواقص في كل مواصفة قبل بنائها.
  • خطر: التغذية الراجعة المتأخرة. العيوب التي تفلت من المراجعات تظهر متأخرة، حين يمسّ الإصلاح الوثائق والتصميم والكود. الإجراء المضاد: مراجعات دقيقة وتصميم مبكر للاختبارات.
  • خطر: انضغاط مرحلة الاختبار. إذا تأخرت البرمجة وكان الموعد ثابتاً، ينكمش وقت الاختبار. الإجراء المضاد: معايير دخول متفق عليها لمرحلة الاختبار، واختبارات مرتبة حسب المخاطر.
  • خطر: التحقق المتأخر من الصلاحية والتكامل دفعة واحدة (Big-bang integration). قد لا يرى المستخدمون البرنامج إلا في اختبار القبول، ودمج كل شيء مرة واحدة يخفي مصدر الإخفاقات. الإجراء المضاد: نماذج أولية، وجولات مع المستخدمين، وتكامل تدريجي.

جرّبها: مولّد الاختبار المبني على المخاطر

أخطاء شائعة

  • الاعتقاد بأن الاختبار يبدأ حين يصل الكود. ففي النموذجين تبدأ المراجعات وتخطيط الاختبار وتصميمه في المراحل الأولى.
  • معاملة الوثيقة المعتمدة على أنها صحيحة. فالاعتماد يعني الاتفاق على المحتوى لا خلوّه من العيوب؛ راجعها على أي حال.
  • الخلط بين ترتيبَي حرف V: تُصمَّم الاختبارات من الأعلى إلى الأسفل مع اعتماد المواصفات، لكنها تُنفَّذ من الأسفل إلى الأعلى.
  • اختبار كل المستويات مقابل الوثيقة نفسها بدلاً من أساس الاختبار الخاص بكل مستوى.
  • قبول تقليص مرحلة الاختبار بصمت بدلاً من التصريح بالمخاطر التي ستبقى دون اختبار.

من منظور ضمان الجودة

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

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

تمرين عملي

ضع اختبارات مشروع على حرف V

المطلوب

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

لكل ناتج عمل، اذكر مستواه على الذراع الأيسر، ومستوى الاختبار المقابل، وفكرة اختبار واحدة. ثم اذكر ترتيب التنفيذ، وخطرين على ضمان الجودة في الخطة مع إجراء مضاد لكل منهما.

المادة
A  «يستطيع المواطن التقدم بطلب رخصة بناء عبر الإنترنت ومتابعة حالته دون زيارة
   مكتب البلدية».
B  «لا يمكن إرسال الطلب قبل رفع كل المستندات الإلزامية؛ وتُعرض المستندات
   الناقصة بأسمائها».
C  «تتحقق البوابة من ملكية العقار عبر خدمة السجل العقاري الوطني».
D  «تُرجع calculateFee(area) ريالين لكل متر مربع، بحد أدنى للرسوم قدره 200 ريال».
الخطوات
  1. طابق كل ناتج عمل (من A إلى D) مع مستواه على الذراع الأيسر لحرف V.
  2. سمِّ مستوى الاختبار المقابل، واكتب له فكرة اختبار واحدة.
  3. اكتب الترتيب الذي ستُنفَّذ به مستويات الاختبار الأربعة.
  4. حدّد خطرين على ضمان الجودة في الخطة، وإجراءً مضاداً لكل منهما.
إظهار الإجابة النموذجية
الإجابة النموذجية

الناتج A متطلب عمل (يصف ما يحتاج المواطن إلى إنجازه) ← اختبار القبول: متقدمون حقيقيون يقدّمون طلبات لعقاراتهم ويتابعون الحالة حتى صدور القرار دون زيارة المكتب، ويؤكد موظفو البلدية قدرتهم على معالجة الطلبات.

الناتج B متطلب نظام (سلوك للنظام كاملاً يستطيع المستخدم ملاحظته) ← اختبار النظام: أرسل الطلب وينقصه مستند إلزامي واحد؛ فيُمنع الإرسال ويُذكر اسم المستند؛ وبعد رفعه ينجح الإرسال.

الناتج C تصميم معماري (يسمّي واجهة مع نظام خارجي) ← اختبار التكامل: يردّ السجل العقاري بـ«المالك غير موجود» أو لا يردّ إطلاقاً؛ فتعرض البوابة رسالة واضحة ولا تعدّ الملكية مؤكدة. وإن سكت التصميم عن ذلك، فاطرح السؤال الآن.

الناتج D تصميم تفصيلي (منطق دالة واحدة) ← اختبار المكوّن: calculateFee(50) تُرجع ⁦200⁩ (الحد الأدنى، لأن ⁦50 × 2 = 100⁩) وcalculateFee(150) تُرجع ⁦300⁩؛ واسأل أيضاً عمّا يجب أن يحدث عند مساحة ⁦0⁩ أو مساحة سالبة.

ترتيب التنفيذ: المكوّن، ثم التكامل، ثم النظام، ثم القبول. أما تصميم الاختبارات فيسير في الاتجاه المعاكس: كان يمكن تصميم اختبارات القبول من الناتج A أثناء كتابته، قبل وجود B وC وD.

مخاطر محتملة، مثلاً: انضغاط مرحلة الاختبار قبل الإطلاق الثابت (الإجراء المضاد: الاتفاق الآن على معايير الدخول وترتيب الاختبارات حسب المخاطر)؛ والتحقق المتأخر من الصلاحية لأن المواطنين لا يرون البوابة إلا في اختبار القبول (الإجراء المضاد: جولة على نموذج أولي مع عدد من المتقدمين أثناء التصميم).

أسئلة شائعة

هل ما زال النموذج الشلالي مستخدماً؟

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

هل نموذج V مجرد نموذج شلالي أُضيف إليه الاختبار؟

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

هل يعني نموذج V أن فريقاً واحداً ينفّذ كل المستويات؟

لا. عادةً يُجري المطورون اختبار المكوّن، ويُجري المطورون أو المختبِرون اختبار التكامل؛ وقد يتولى فريق اختبار مستقل اختبار النظام، ويُفضَّل أن يُجري المستخدمون المقصودون أو ممثلو العميل اختبار القبول. ويُتفق على توزيع الأدوار في خطة الاختبار.

المراجع

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

تدرّب بأدوات متقن

المتطلبات ← حالات اختبار

حوّل قائمة متطلبات مرقّمة إلى حالات اختبار قابلة للتتبّع مع مصفوفة تربط المتطلبات بالاختبارات.

تصميم الاختبارات

للتعمّق أكثر

تقدّمك في هذا الموضوع

جزء من مسار تعلم ضمان الجودة

قبل هذا الموضوع