إعادة إنتاج الإخفاقات
إعادة إنتاج الإخفاق (Reproducing a Failure) تعني أن تجعله يحدث مرة أخرى عن قصد، بإعادة تهيئة الظروف التي ظهر فيها أول مرة. مثال ذلك: أثناء تشغيل الاختبارات يؤدي اختيار «تأكيد الطلب» إلى ظهور رسالة «حدث خطأ ما». وتكون قد أعدت إنتاج الإخفاق حين تعرف أيّ حساب وأيّ بيانات وأيّ بيئة وأيّ خطوات تجعله يظهر من جديد، والأفضل أن يظهر في كل مرة.
يصف منهج ISTQB للمستوى التأسيسي تصحيح الأخطاء (Debugging) بأنه إعادة إنتاج الإخفاق، وتشخيصه (أي إيجاد سببه)، وإصلاح السبب. والتشخيص والإصلاح عمل المطور غالباً، أما إعادة الإنتاج فهي أكثر ما يُسهم فيه المختبِر، لأنه رأى الإخفاق ويعرف ظروفه. وهي تُبنى على درس أدلة الاختبار: فلقطات الشاشة والسجلات والطوابع الزمنية التي التقطتها تخبرك من أين تبدأ.
لماذا يهم
الإخفاق الذي لا يستطيع أحد أن يجعله يتكرر يصعب إصلاحه، ولا يمكن تأكيد إصلاحه بإعادة الاختبار. فإذا لم يستطع المطور إعادة إنتاجه، يعود التقرير غالباً بعبارة «تعذّرت إعادة الإنتاج» (Cannot Reproduce)، ويبقى العيب في المنتج حيث قد يصادفه المستخدمون. والظروف الدقيقة تختصر التشخيص: فعبارة «يفشل لأي عميل عنوانه المحفوظ بلا رمز بريدي» تشير إلى جزء واحد من الشيفرة بدلاً من عملية الشراء كلها.
وبالنسبة إلى المختبِر، إعادة الإنتاج فحصٌ لملاحظته هو أيضاً: فالمحاولة من جديد في ظروف مضبوطة تُظهر هل الإخفاق حقيقي أم نتج عن سهو منك. والخطوات التي تعيد إنتاجه هي أساس اختبار التأكيد (Confirmation Testing) بعد الإصلاح؛ فمن دون خطوات موثوقة لا يثبت نجاح إعادة الاختبار الكثير.
ابدأ من ظروف الإخفاق الأول
حين يفشل اختبار، لا تبدأ بتغيير الأشياء. دوّن أولاً كل ظروف تلك اللحظة، ثم كرّر الإخفاق كما حدث تماماً: البناء (Build) والبيئة والحساب والبيانات والخطوات نفسها. فإن فشل مرة أخرى، صار لديك إخفاق قابل لإعادة الإنتاج وخط أساس تقارن به. وإن لم يفشل، فثمة شيء مختلف عن المرة الأولى، وهذا الاختلاف أول خيط بين يديك.
وسجّل أكثر من خطوات حالة الاختبار:
- البناء والبيئة: رقم البناء، والبيئة، والإعدادات، وأعلام الميزات (Feature Flags)، أي المفاتيح التي تشغّل ميزة أو توقفها دون بناء جديد.
- جهاز العميل: المتصفح وإصداره، ونظام التشغيل، والجهاز، وحجم الشاشة، واللغة واتجاه الكتابة؛ فالصفحة العربية المكتوبة من اليمين إلى اليسار قد تفشل حيث تنجح الصفحة الإنجليزية.
- المستخدم: الدور والصلاحيات وحالة الحساب، مثل حساب جديد أو مقفل أو منتهي الاشتراك.
- البيانات: قيم الإدخال بالضبط والملفات والسجلات المعنية، مثل محتوى السلة والقسيمة.
- الحالة: ما حدث قبل ذلك في الجلسة، وملفات تعريف الارتباط (Cookies) والذاكرة المؤقتة.
- الوقت مع المنطقة الزمنية، لكي يمكن مطابقة الإخفاق مع سجلات الخادم.
اعزل المتغيرات: غيّر شيئاً واحداً في كل مرة
بعد أن يتكرر الإخفاق، اكتشف أيّ الظروف مؤثرة. عامِل كل ظرف على أنه متغير، وغيّر متغيراً واحداً فقط بين محاولة وأخرى مع تثبيت الباقي. فإن اختفى الإخفاق حين غيّرت المتصفح، فالمتصفح جزء من المحفّز (Trigger)؛ وإن بقي، فالمتصفح ليس عاملاً: احذفه من الخطوات واذكر في التقرير أنك استبعدته. أما إذا غيّرت شيئين معاً، فلن تعرف أيهما أحدث الفرق.
ولإيجاد المتغيرات المرشحة، قارن حالة فاشلة بحالة ناجحة: حسابين، أو طلبين، أو مجموعتي بيانات جنباً إلى جنب. وكثيراً ما يكون الاختلاف حقلاً واحداً، مثل سطر عنوان فارغ أو اسم طويل أو عملة أخرى. وابدأ بالمتغيرات الأرجح تأثيراً والأرخص تغييراً: البيانات، والمستخدم، والمتصفح، والبيئة.
الإجابة: في كل مرة
سؤال 2: غيّر متغيراً واحداً: هل يختفي الإخفاق؟المتصفح أو المستخدم أو البيانات أو البيئة: واحد في كل محاولةالإجابة: نعم
النتيجة: جزء من المحفّزأبقِه في التقرير، وقارن القيمة الفاشلة بالقيمة الناجحةالإجابة: لا، ما زال يفشل
النتيجة: ليس عاملاًاحذفه من الخطوات، واذكر أنه مستبعد، وغيّر المتغير التالي
الإجابة: أحياناً
سؤال 3: كرّر عدداً ثابتاً من المرات: هل ينقل تغيير ظرف واحد المعدل إلى الصفر أو إلى كل المحاولات؟مثلاً 3 من 20 قبل التغيير، و0 من 20 بعدهالإجابة: نعم
النتيجة: وُجد المتغير الخفيجزء من المحفّز: أضفه إلى الظروف، ثم قِس المعدل من جديدالإجابة: لا
النتيجة: ما زال متقطعاًجرّب الظرف التالي، أو أبلغ عنه مع المعدل والطوابع الزمنية والأدلة
الإجابة: لا يتكرر
سؤال 4: هل تختلف ظروف اليوم عما تُظهره الأدلة؟البناء وحالة الحساب والبيانات والوقتالإجابة: نعم
النتيجة: أعد تهيئة الظروف الأصليةاستعد بيانات الإخفاق الأول أو حالته أو بناءه، ثم كرّرالإجابة: لا
النتيجة: لم يُعَد إنتاجهأبلغ عنه مع الأدلة والمحاولات التي أجريتها
بعد معرفة المحفّز، احذف الخطوات واحدة تلو الأخرى حتى تصل إلى الحد الأدنى لإعادة الإنتاج.
- يفشل لمستخدم واحد فقط: قارن بيانات هذا المستخدم ودوره وإعداداته بمستخدم آخر يعمل معه السيناريو.
- يفشل في متصفح واحد فقط: اقرأ وحدة التحكم (Console) في ذلك المتصفح، وكرّر المحاولة في إصدار آخر منه.
- يفشل فقط بعد إجراء سابق: الحالة التي يتركها ذلك الإجراء متغير أيضاً.
اختصره إلى الحد الأدنى لإعادة الإنتاج
تحمل إعادة الإنتاج الأولى عادةً خطوات لا علاقة لها بالإخفاق: فقد كنت في الخطوة 17 من حالة اختبار طويلة. والحد الأدنى لإعادة الإنتاج (Minimal Reproduction) هو أصغر مجموعة من الشروط المسبقة والخطوات ما زالت تُحدث الإخفاق. احذف خطوة أو شرطاً مسبقاً واحداً في كل مرة ثم أعد التشغيل: فإن بقي الإخفاق فاتركها محذوفة، وإن توقف فأعدها. وتوقف حين تصبح كل خطوة باقية ضرورية.
والنتيجة تقرير يستطيع المطور اتباعه في دقيقة، واختبار تأكيد جاهز للإصلاح يصبح غالباً حالة اختبار انحدار لاحقاً. واذكر مدى ثباته رقماً، مثل «5 من 5 محاولات»، لا بكلمة «دائماً».
مثال تطبيقي: طلب يفشل لعميل واحد
أثناء تشغيل اختبارات الانحدار على بيئة Staging، تفشل حالة الاختبار TC-214 «إنشاء طلب ببطاقة محفوظة»: فبعد اختيار «تأكيد الطلب» تعرض الصفحة «حدث خطأ ما»، وتُظهر لوحة الشبكة أن POST /api/orders أعاد الرمز 500. يسجّل المختبِر البناء 4.12.0، والحساب cust-07، وسلة من ثلاثة منتجات مع قسيمة، والمتصفح، والوقت، ثم يغيّر شيئاً واحداً في كل محاولة. وكل سطر أدناه جولة من المحاولات وما أظهرته، والتقرير بعدها هو النتيجة.
- الظروف نفسها، مرتين: يفشل في المرتين. الإخفاق قابل لإعادة الإنتاج.
- Firefox بدلاً من Chrome: يفشل. المتصفح ليس عاملاً.
- الحساب cust-09 بدلاً من cust-07: يُنشأ الطلب. الحساب مؤثر، ومقارنة الحسابين تكشف اختلافاً واحداً: العنوان المحفوظ في cust-07 رمزه البريدي فارغ.
- إضافة رمز بريدي إلى cust-07: ينجح. حذفه من cust-09: يفشل. الرمز البريدي الفارغ هو المحفّز.
- حذف الخطوات واحدة تلو الأخرى: يمكن الاستغناء عن القسيمة وعن منتجين من الثلاثة وعن البطاقة المحفوظة؛ فمنتج واحد مع الدفع عند الاستلام يفشل أيضاً.
- الخطوات المختصرة، مكرّرة 5 مرات: 5 إخفاقات؛ ومع رمز بريدي: 0 من 5. ولا يذكر المتطلب ما يجب أن يحدث عند ترك الرمز البريدي فارغاً، لذلك يذكر التقرير النتيجتين المقبولتين، ويسأل المختبِر مالك المنتج أيّهما المقصودة.
العنوان: إنشاء الطلب يعيد 500 عندما يكون الرمز البريدي في العنوان المحفوظ فارغاً
البناء: 4.12.0 على Staging — المتصفحات: Chrome وFirefox (يفشل في كليهما)
الشرط المسبق: عميل مسجّل الدخول، رمزه البريدي في العنوان المحفوظ فارغ
الخطوات:
1. أضف أي منتج متوفر إلى السلة.
2. افتح السلة واختر «إتمام الشراء».
3. أبقِ العنوان المحفوظ، واختر «الدفع عند الاستلام»، ثم اختر «تأكيد الطلب».
النتيجة المتوقعة: يُنشأ الطلب، أو يطلب النموذج رمزاً بريدياً
النتيجة الفعلية: «حدث خطأ ما»، ويعيد POST /api/orders الرمز 500
المعدل: 5 من 5 محاولات؛ ومع رمز بريدي: 0 من 5
المستبعَد: المتصفح والقسيمة وعدد المنتجات وطريقة الدفع (يفشل بالبطاقة المحفوظة أيضاً)الإخفاقات المتقطعة: أعد الإنتاج بالتكرار
بعض الإخفاقات لا يظهر إلا في بعض المحاولات بالخطوات نفسها. والإخفاق المتقطع (Intermittent Failure) له سبب رغم ذلك، هو متغير لم تكتشفه بعد أو لا تستطيع التحكم فيه: التوقيت، أو تعديل مستخدمَين البيانات نفسها في اللحظة نفسها، أو حالة تركها اختبار سابق، أو الذاكرة المؤقتة، أو وقت اليوم، أو أيّ الخوادم المتعددة عالج الطلب.
والاختبار المؤتمت الذي يتصرف بهذه الطريقة يسمى اختباراً متذبذباً (Flaky Test)؛ وقد يكون السبب في الاختبار أو البيئة أو المنتج، والطريقة نفسها تنطبق. لا تصفه بأنه «عشوائي»، بل قِسه:
- كرّر الخطوات نفسها عدداً ثابتاً من المرات، 20 مثلاً، واحسب مرات الفشل: «3 من 20» معدل إعادة إنتاج (Reproduction Rate).
- دوّن وقت كل محاولة فاشلة لكي تُطابَق مع سجلات الخادم، وقارن سجل محاولة فاشلة بسجل محاولة ناجحة.
- غيّر ظرفاً واحداً وكرّر العدد نفسه من المرات. فالظرف الذي ينقل المعدل إلى 0 من 20، أو إلى 20 من 20، جزء من المحفّز على الأرجح.
- إن بقي غير ثابت، فأبلغ عنه مع الأدلة والظروف والمعدل واصفاً إياه بأنه متقطع، ولا تقبل أبداً تشغيلاً ناجحاً واحداً دليلاً على إصلاحه.
أخطاء شائعة
- تغيير عدة أشياء بين محاولة وأخرى، فلا تعرف أيّ تغيير كان المؤثر.
- الإبلاغ بسلسلة الخطوات الطويلة الأولى كما هي، بما فيها خطوات لا علاقة لها بالإخفاق.
- كتابة «دائماً» أو «عشوائي» بدلاً من المعدل الملاحَظ، أو وصف الإخفاق بأنه متقطع بعد محاولة واحدة.
- عدم تسجيل ظروف الإخفاق الأول، فيتعذّر إعادة تهيئتها لاحقاً.
- إغلاق إخفاق متقطع بعبارة «تعذّرت إعادة الإنتاج» بعد محاولة أو محاولتين ناجحتين.
- إعادة الإنتاج ببيانات عملاء حقيقيين أو على بيئة الإنتاج دون موافقة، بدلاً من تهيئة بيانات بالشكل نفسه في بيئة الاختبار.
من منظور ضمان الجودة
في الفريق الحقيقي، تبدأ إعادة الإنتاج لحظة رؤيتك نتيجة غير متوقعة: التقط الأدلة، ودوّن الظروف، وحاول مرة أخرى قبل أن تتابع. واتفق مع قائد الاختبار على المدة التي تخصصها لعزل الإخفاق أثناء التشغيل؛ فإذا انتهت، فأبلغ بما لديك وتابع. واذكر ما استبعدته («يفشل في Chrome وFirefox، لأي مستخدم عنوانه بلا رمز بريدي»)، كي لا يكرر المطور محاولاتك.
وابقَ متاحاً للمطور، فقد يعيد إنتاج الإخفاق على مستوى أدنى، عبر الواجهة البرمجية أو في اختبار وحدة، انطلاقاً من خطواتك المختصرة؛ وقدّم له معرّفات الطلبات (Request IDs) والطوابع الزمنية ليجد سجلات الخادم. واحفظ الحد الأدنى لإعادة الإنتاج مع التقرير: فهو اختبار التأكيد بعد الإصلاح ومرشح لحزمة الانحدار.
تمرين عملي
اعزل إخفاق رفع صورة الملف الشخصي
يقول تقرير إن تغيير صورة الملف الشخصي يفشل برسالة «Upload failed». ويسمح المتطلب بملفات JPG أو PNG لا يتجاوز حجمها 5 ميغابايت. المحاولات حتى الآن في الجدول، وكلها على البناء نفسه وفي بيئة الاختبار نفسها.
استنتج ما تُظهره المحاولات وما لا تُظهره، وقرّر ما ستجربه بعد ذلك، واكتب الحد الأدنى لإعادة الإنتاج.
# User Browser File Format Size Network Result
1 sara01 Chrome team.png PNG 4.8 MB office Upload failed
2 sara01 Chrome team.png PNG 4.8 MB office Upload failed
3 sara01 Firefox team.png PNG 4.8 MB office Upload failed
4 omar02 Chrome team.png PNG 4.8 MB office Upload failed
5 sara01 Chrome team.jpg JPG 4.8 MB office Upload failed
6 sara01 Chrome team.png PNG 1.9 MB office photo saved
7 omar02 Firefox badge.jpg JPG 0.2 MB office photo saved- حدّد المحاولات التي تكرر الظروف نفسها، واذكر ما تثبته.
- لكل محاولة تغيّر شيئاً واحداً فقط، سمِّ المتغير واذكر هل هو مؤثر.
- حدّد المحاولة التي لا يمكن تفسيرها، واشرح السبب.
- سمِّ ظرفاً لم يتغير قط، ثم خطّط للمحاولات التالية واكتب الحد الأدنى لإعادة الإنتاج.
إظهار الإجابة النموذجية
المحاولتان 1 و2 تكرران الظروف نفسها وكلتاهما تفشل: الإخفاق قابل لإعادة الإنتاج.
المحاولات 3 و4 و5 تغيّر كلٌّ منها شيئاً واحداً (المتصفح، والمستخدم، والصيغة) وكلها ما زالت تفشل، فلا شيء منها عامل. والمحاولة 6 تغيّر حجم الملف فقط (الصورة نفسها مصدّرة من جديد بحجم أصغر) فتنجح: الحجم عامل مؤثر، مع أن 4.8 ميغابايت تبدو ضمن حد 5 ميغابايت.
المحاولة 7 تغيّر خمسة أشياء معاً. وهي تنجح، لكنك لا تستطيع أن تقول أيّ تغيير أحدث الفرق، فلا تضيف شيئاً.
الشبكة لم تتغير قط، فهي غير مستبعدة. المحاولات التالية: الصورة نفسها بأحجام بين 1.9 و4.8 ميغابايت (مثل 3 و4 ميغابايت) لإيجاد النقطة التي يبدأ عندها الإخفاق، وملف بحجم 5 ميغابايت بالضبط وآخر أكبر منه بقليل، ورفع ملف بحجم 4.8 ميغابايت من شبكة أخرى. وسجّل الحجم الدقيق لكل ملف بالبايت: فالأدوات تختلف في عدّ الميغابايت 1,000,000 بايت أو 1,048,576 بايت، لذا قد يتجاوز ملف «4.8 ميغابايت» بالفعل حداً قدره 5,000,000 بايت.
الحد الأدنى لإعادة الإنتاج، على أن يُحدَّث بعد تلك المحاولات: أي مستخدم مسجّل الدخول على شبكة المكتب؛ افتح صفحة الملف الشخصي، واختر «تغيير الصورة»، ثم اختر ملف PNG أو JPG بحجم 4.8 ميغابايت (مع ذكر حجمه بالبايت)، ثم اختر «حفظ». النتيجة المتوقعة: تُحفظ الصورة، لأن المتطلب يسمح بما يصل إلى 5 ميغابايت. النتيجة الفعلية: «Upload failed». المعدل: 5 من 5 محاولات بملفات 4.8 ميغابايت، في متصفحين ولمستخدمَين وبالصيغتين؛ بينما تُحفظ ملفات 1.9 و0.2 ميغابايت.
أسئلة شائعة
هل إعادة إنتاج الإخفاق عمل المختبِر أم المطور؟
كلاهما يُسهم. يصف منهج ISTQB تصحيح الأخطاء بأنه إعادة إنتاج وتشخيص وإصلاح. وعملياً يقدّم المختبِر إعادة إنتاج موثوقة وظروفها لأنه رأى الإخفاق، وكثيراً ما يعيد المطور إنتاجه مرة أخرى في أداة تصحيح الأخطاء أو على مستوى أدنى. أما إيجاد العيب في الشيفرة وإصلاحه فعمل المطور عادةً.
ماذا أفعل إن لم أستطع إعادة إنتاج الإخفاق إطلاقاً؟
أبلغ عنه رغم ذلك إن كانت الأدلة تُظهر أنه حدث: أرفق الأدلة والظروف والمحاولات التي أجريتها، واذكر صراحةً أنك لم تستطع إعادة إنتاجه. بعض الفرق تغلق التقارير بحالة «تعذّرت إعادة الإنتاج»، لكن هذا يغلق التقرير ولا يُثبت أن المنتج سليم. وراقب الاختبارات والسجلات ذات الصلة: فتكراره مرة ثانية يمنحك ظروفاً جديدة للمقارنة.
كم مرة يجب أن أكرر إخفاقاً متقطعاً؟
لا يوجد عدد ثابت. كرّر بما يكفي ليكون للمعدل معنى قياساً بمدى تكرار الإخفاق: فإذا كان يفشل مرة في كل عشر محاولات تقريباً، فثلاث محاولات ناجحة لا تثبت الكثير. واستخدم عدد التكرارات نفسه قبل التغيير وبعده لتتمكن من مقارنة المعدلين؛ وفي الاختبارات المؤتمتة يمكن لمشغّل الاختبارات (Test Runner) أن يكرر الاختبار عنك.
هل الإخفاق المتقطع هو نفسه الاختبار المتذبذب؟
ليس تماماً. تصف كلمة «متذبذب» (Flaky) عادةً اختباراً مؤتمتاً تتغير نتيجته بين التشغيلات دون تغيير في الشيفرة، وقد يكون السبب في الاختبار أو البيئة أو المنتج. أما الإخفاق المتقطع فسلوك للمنتج يُلاحَظ بأي وسيلة، يدوية أو مؤتمتة. والتشخيص واحد في الحالتين: التكرار، والمعدل، وتغيير ظرف واحد في كل مرة.
المراجع
- ISTQB Certified Tester Foundation Level (CTFL) v4.0المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
- ISTQB Glossaryالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
- Eradicating Non-Determinism in Tests (Martin Fowler)لماذا تُفقد الاختبارات المتذبذبة الحزمةَ قيمتها، وأسبابها الشائعة (العزل وعدم التزامن والخدمات البعيدة والوقت وتسرّب الموارد)، والحجر كاستجابة.
تدرّب بأدوات متقن
مقارنة مستندي JSON دلالياً وإبراز القيم المضافة والمحذوفة والمتغيرة.
قارن استجابتي API (مثل بيئة التجريب مقابل الإنتاج) واحصل على قائمة بكل فرق بنيوي أو في القيم.
قارن نصّين سطراً بسطر أو كلمةً بكلمة مع إبراز الاختلافات.
تحليل سلاسل User-Agent إلى المتصفح والإصدار والمحرك ونظام التشغيل ونوع الجهاز مع كشف الروبوتات.
حوّل الطوابع الزمنية (ثوانٍ، ميلي ثانية، ميكرو ثانية) إلى تواريخ مقروءة وبالعكس، بأي منطقة زمنية.
للتعمّق أكثر
تقدّمك في هذا الموضوع
سجّل الدخول لتتابع تقدّمك
علّم الموضوعات مكتملة، وتابع من حيث توقفت، وافتح امتحانات التخصص.