سيناريوهات الاختبار

لماذا يهم

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

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

ما سيناريو الاختبار، وما الذي لا يُعدّ سيناريو

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

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

• جيد: «عميل يحاول إلغاء طلب خرج للتوصيل فعلاً».
• غامض جداً: «اختبار إلغاء الطلب». يسمّي ميزة لا موقفاً.
• مفصّل جداً: «افتح الطلب ⁦1042⁩ واضغط إلغاء ثم نعم وتحقق من الرسالة». هذه حالة اختبار.

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

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

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

TS-04  عميل يحاول إلغاء طلب خرج للتوصيل

TC-04.1  الطلب «خرج للتوصيل»، مدفوع بالبطاقة
         المتوقع: رفض الإلغاء؛ يذكر التطبيق السبب ويعرض رابطاً للدعم؛
                  حالة الطلب والدفع دون تغيير
TC-04.2  الطلب «خرج للتوصيل»، الدفع عند الاستلام
         المتوقع: الرفض بالرسالة نفسها كما في TC-04.1؛ الحالة دون تغيير
TC-04.3  الطلب «تم التوصيل»، مدفوع بالبطاقة
         المتوقع: الرفض؛ حالة الطلب والدفع دون تغيير

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

استخراج السيناريوهات من القصص ومساراتها

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

ابحث عن ثلاثة أنواع من المسارات. المسار الرئيسي (Main Flow)، ويسمّى كثيراً المسار السعيد (Happy Path)، هو الطريق المعتاد إلى الهدف. والمسار البديل (Alternative Flow) طريق صالح آخر لا خطأ فيه: طريقة دفع أخرى، أو مستخدم يغيّر رأيه ويتوقف. ومسار الاستثناء (Exception Flow) هو ما يحدث حين يسوء أمر ما: قاعدة ترفض الإجراء، أو تتعطّل تبعيةٌ مثل مزوّد الدفع، أو تتغيّر البيانات أثناء تصرّف المستخدم. وينتهي معظم مسارات الاستثناء دون بلوغ الهدف، لكن بعضها يتعافى ويعود إلى المسار الرئيسي.

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

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

مثال تطبيقي: إلغاء طلب بقالة

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

ليس لـTS-05 وTS-06 نتيجة متوقعة في المعايير: فلا شيء يذكر ما يحدث حين يفشل الاسترداد، ولا أي لحظة تُحتسب في الإلغاء المتأخر، فتح النافذة أم التأكيد. فصار كلاهما سؤالاً لمالك المنتج قبل أن يكتب أحد حالة اختبار.

GRO-31  إلغاء طلب
بصفتي عميلاً، أريد إلغاء طلب قدّمته،
كي لا أدفع ثمن شيء لم أعد أحتاج إليه.

AC1  يمكن إلغاء الطلب إلى أن يخرج للتوصيل.
AC2  الإلغاء يردّ المبلغ المدفوع كاملاً إلى البطاقة التي دُفع بها؛
     ولا يحتاج طلب الدفع عند الاستلام إلى استرداد.
AC3  لا يمكن إلغاء طلب خرج للتوصيل: يذكر التطبيق السبب
     ويعرض رابطاً للدعم.
AC4  بعد الإلغاء يتلقى العميل تأكيداً في التطبيق وبرسالة SMS.
حالات الطلب: جديد > مجهَّز > خرج للتوصيل > تم التوصيل، أو ملغى

السيناريوهات
TS-01  رئيسي    AC1, AC2, AC4
       إلغاء طلب مدفوع بالبطاقة قبل خروجه للتوصيل: يُلغى الطلب،
       ويعود المبلغ كاملاً إلى البطاقة، ويصل التأكيد في التطبيق وبرسالة SMS
TS-02  بديل     AC1, AC2, AC4
       إلغاء طلب بالدفع عند الاستلام: يُلغى الطلب، بلا استرداد، ويصل التأكيد
TS-03  بديل     بلا معيار (خطوة التأكيد في المسار)
       فتح نافذة الإلغاء ثم الإبقاء على الطلب: يبقى الطلب كما كان
TS-04  استثناء  AC1, AC3
       محاولة إلغاء طلب خرج للتوصيل: يُرفض مع ذكر السبب ورابط للدعم
TS-05  استثناء  بلا معيار
       فشل ردّ المبلغ إلى البطاقة لدى مزوّد الدفع: النتيجة المتوقعة؟  Q1
TS-06  استثناء  AC1, AC3
       يخرج الطلب للتوصيل بينما نافذة الإلغاء مفتوحة:
       أي لحظة تُحتسب، فتح النافذة أم التأكيد؟  Q2

تغطية السيناريوهات: هل ينقصنا شيء؟

تسأل تغطية السيناريوهات هل يمارس سيناريو واحد على الأقل كل بند من بنود أساس الاختبار (Test Basis) الذي اخترته، مثل معايير القبول والمسارات والحالات والأدوار والمخاطر. اربط السيناريوهات ببنودها في جدول فيه صف لكل سيناريو وعمود لكل بند، وهو مصفوفة تتبّع (Traceability Matrix) بسيطة. فالبند الذي لا سيناريو له ثغرة في اختباراتك، والسيناريو الذي لا بند له ثغرة في المتطلب أو عمل خارج القصة، ويستحق سؤالاً.

• تغطية المعايير: ⁦4⁩ من ⁦4⁩. فالمعيار AC1 تمارسه أربعة سيناريوهات، وكلٌّ من AC2 وAC3 وAC4 يمارسه سيناريوهان.
• تغطية المسارات: ⁦6⁩ من ⁦6⁩، لكن للمسارات التي في القائمة فقط؛ فالمسار الذي لم يفكّر فيه أحد ليس في المقام.
• التغطية تعدّ البنود لا العمق: الفحوص الأساسية في AC2، أي المبلغ بالضبط والبطاقة نفسها، مكانها حالات اختباره.
• وتبقى هذه تغطية على الورق: فلا تُمارَس المعايير فعلاً إلا حين تُنفَّذ حالات الاختبار المشتقة من السيناريوهات، ولا يثبت تحقّقها إلا حين تنجح تلك الاختبارات.

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

أسئلة شائعة

المراجع

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• ISTQB GlossaryISTQBالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
• Gherkin Reference — CucumberCucumberصياغة Gherkin للمواصفات القابلة للتنفيذ: Feature وRule وScenario، وخطوات Given/When/Then، وBackground وScenario Outline وExamples.