نماذج تطوير البرمجيات

لماذا يهم

النموذج يحدد ما يستطيع المختبِر فعله ومتى. ويعدّد CTFL الإصدار ⁦4.0⁩ ما يتأثر باختيار دورة الحياة: نطاق أنشطة الاختبار وتوقيتها، ودرجة تفصيل توثيق الاختبار، واختيار تقنيات الاختبار ونهجه، ومدى أتمتة الاختبار، ودور المختبِر ومسؤولياته.

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

التتابعي والتكراري والتزايدي

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

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

كيف يختلف الاختبار في كل نموذج

في كل نموذج أنشطة الاختبار نفسها، من تخطيط الاختبار وتحليله مروراً بالتصميم والتهيئة والتنفيذ وصولاً إلى إتمام الاختبار. وما يتغير هو الجوانب الخمسة التي يعدّدها CTFL الإصدار ⁦4.0⁩: نطاق هذه الأنشطة وتوقيتها، ودرجة تفصيل التوثيق، والتقنيات، ومدى الأتمتة، ودور المختبِر.

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

مثال تطبيقي: تطبيق العيادة بثلاث طرق

لتطبيق العيادة ثلاث خصائص: الحجز (B)، والتذكير برسائل SMS (R)، والدفع الإلكتروني (P). ويوضح المخطط الزمني متى تُكتب مواصفات كل منها وتُبنى وتُختبر.

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

Clinic booking app: Booking (B), Reminders (R), Payment (P)

Sequential:
  [specify B R P] [design] [build] [test B R P] -> release B R P

Incremental:
  [B: specify, build, test] -> release B
  [R: specify, build, test + regression of B] -> release B R
  [P: specify, build, test + regression of B R] -> release B R P

Iterative:
  [rough B R P] -> feedback -> [better B R P] -> feedback -> [final B R P] -> release

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

اختيار النموذج حسب السياق

لا يوجد نموذج هو الأفضل دائماً؛ فالاختيار يعتمد على السياق. وعادةً تقرره المؤسسة أو قائد المشروع، لكن المختبِر الذي يفهم الأسباب يستطيع تكييف نهج الاختبار والإشارة إلى مخاطر الاختبار. اسأل:

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

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

أسئلة شائعة

المراجع

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• ISTQB GlossaryISTQBالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
• Manifesto for Agile Software DevelopmentThe Agile Manifesto authors · 2001القيم الأربع لتطوير البرمجيات الرشيق (Agile)، مثل تقديم البرمجيات العاملة على التوثيق الشامل، والاستجابة للتغيير على اتباع الخطة.
• The 2020 Scrum GuideKen Schwaber and Jeff Sutherland · 2020تعريف Scrum: مسؤولياته وأحداثه ومخرجاته، بما فيها تعريف الإنجاز (Definition of Done) الذي يساعد الاختبار على تحقيقه.