صيد الأخطاء والاستكشاف الموجّه بالمخاطر

لماذا يهم

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

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

الاستكشاف الموجّه بالمخاطر: صوّب قبل أن تستكشف

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

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

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

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

الاستدلالات والجولات أدواتٍ للصيد

يشرح دليل الاختبار الاستكشافي الاستدلالات (Heuristics)، وهي قواعد تقريبية تقترح ما تجرّبه بعد ذلك، والجولات (Tours)، وهي مسارات ذات موضوع عبر المنتج. وفي الصيد تختارها بحسب الخطر الذي تستهدفه، كي تهاجم الأداةُ الإخفاقَ الذي تخشاه بدلاً من تكرار المسار السعيد (Happy Path)، وتُبقي قائمة الأخطاء النموذجية من درس تخمين الأخطاء (Error Guessing) في متناول يدك. وهذه خلاصة سريعة مقرونة بمخاطر شائعة:

• مبالغ خاطئة: نوّع المدخلات، مثل الخصومات والتقريب والمبالغ الصفرية والقصوى والمجاميع التي لا تنقسم بالتساوي. ورغم اسمها، ليست جولة المال (Money) هي الأداة هنا، فهي تزور الميزات التي تبيع المنتج، تلك التي تُعرض في العروض التوضيحية.
• بيانات مفقودة أو غير متسقة: جولة FedEx، أي تتبّع سجل واحد عبر كل شاشة وبريد وملف تصدير وواجهة برمجية تلمسه.
• تعارض الحالات: نوّع الحالات والتسلسلات، مثل تبويبين وجهازين والرجوع والتقدّم والإرسال مرتين؛ وجولة الوسواس (Obsessive-compulsive) تكرر فعلاً واحداً حتى ينهار شيء.
• تعطّل الاعتماديات: جولة المخرّب (Saboteur) والمقاطعة، مثل شبكة بطيئة أو مقطوعة، ومهلات تنتهي، ودفع مرفوض في بيئة الدفع التجريبية.
• وصول خاطئ: تقمّص شخصية، مثل فرد أُزيل من الحساب، أو ضيف، أو مستخدم انتهت جلسته.
• العرض والتوطين: جولة عارض الأزياء (Supermodel) على العربية والإنجليزية، والتخطيط من اليمين إلى اليسار، والأسماء الطويلة، والتكبير.
• زوايا مهملة: جولة الأزقة الخلفية (Back alley) في الإعدادات وصفحات الأخطاء والحدود التي لا يعرضها أحد.

جرّبها: مولّد الحالات الحدّية جرّبها: مولّد مجموعات الأحرف الخاصة

تنظيم حملة صيد الأخطاء

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

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

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

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

مثال عملي: حملة صيد قبل إصدار الحسابات العائلية

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

يأخذ ثنائيان المحفظة، لأن الخصم المزدوج أو الاسترداد الخاطئ هو الخطر الأعلى. وتأخذ الثنائيات الأخرى آخرَ موعد شاغر يحجزه فردان في اللحظة نفسها، والخصوصية بعد إزالة أحد الأفراد، وقاعدة الإلغاء قبل ⁦24⁩ ساعة، والشاشات العربية والإنجليزية. وفي صباح اليوم التالي يفرز قائد الجودة وقائد التطوير ⁦31⁩ نتيجة خاماً، ثم يرسل قائد الجودة هذا الملخص (VH عالٍ جداً، وH عالٍ، وM متوسط):

• حرج (Critical): تُخصم المحفظة مرتين عند الضغط على «ادفع» مرة أخرى بعد انتهاء المهلة.
• حرج (Critical): يستطيع فرد أُزيل من الحساب أن يفتح مواعيد العائلة القادمة من رابط محفوظ.
• سؤال: الإلغاء قبل الموعد بـ⁦24⁩ ساعة تماماً يُسترد مبلغه، لكن القاعدة تقول «بأكثر من ⁦24⁩ ساعة». أيهما المقصود؟

Bug bash: family accounts    build 4.6.0 (staging)    90 min, 12 people, 6 pairs

Risk (level)                    Pairs  Raw  New defects  Highest severity
Wallet charge and refund (VH)     2     9        4       Critical
Last slot, two members (VH)       1     5        2       Major
Removed member privacy (VH)       1     4        1       Critical
24 h cancellation rule (H)        1     6        2       Major
Arabic and English screens (M)    1     7        3       Minor

Triage:      31 raw -> 12 new defects, 9 duplicates, 4 known issues,
             3 questions, 3 not a defect
Not reached: refund to an expired card (no sandbox card for it)
Risk now:    wallet and privacy stay VH until the Critical fixes pass confirmation
             testing; refunds to expired cards are still untested;
             slot, cancellation and screens lower once their fixes are confirmed
Follow-up:   6 regression cases (2 automated at API level),
             2 charters for the next sprint

الإبلاغ عن الحصيلة

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

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

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

أسئلة شائعة

المراجع

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• Explore It! Reduce Risk and Increase Confidence with Exploratory Testing (Elisabeth Hendrickson)The Pragmatic Bookshelf · 2013منهج الاختبار الاستكشافي: المواثيق والاستدلالات لتنويع المدخلات والحالات، وكيف يكمّل الاختبارات المكتوبة.
• Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design (James A. Whittaker)Addison-Wesley (Pearson) · 2009الكتاب الذي نظّم الاختبار الاستكشافي حول «الجولات» — طرق منظمة لاستكشاف الميزات والبيانات ورحلات المستخدم.
• Session-Based Test Management (Jonathan Bach)Satisfice, Inc. · 2000الوصف الأصلي لإدارة الاختبار القائمة على الجلسات: جلسات استكشافية محددة بميثاق ومدة، وأوراق الجلسات، وجلسات الاستخلاص (Debrief) بعدها.