اختبار التأكيد واختبار الانحدار

لماذا يهم

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

ويقدّم النشاطان دليلين مختلفين. فإغلاق العيب دون اختبار تأكيد يعلن إصلاحاً قد لا يكون موجوداً، وتأكيد الإصلاح دون اختبار انحدار يوحي بإصدار آمن مع أن أحداً لم يتحقق. واختيار نطاق انحدار يناسب الوقت المتاح، وتحديد ما يُؤتمت منه، قرارٌ ستتخذه بعد كل إصلاح تقريباً.

اختبار التأكيد: هل أُصلح العيب فعلاً؟

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

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

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

اختبار الانحدار: هل كسر التغيير شيئاً آخر؟

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

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

• إصلاح العيوب والميزات الجديدة وإعادة الهيكلة (Refactoring)، أي إعادة ترتيب الشيفرة دون تغيير ما تفعله.
• ترقية المكتبات أو أُطر العمل أو قاعدة البيانات أو نظام التشغيل.
• تغييرات الإعدادات وأعلام الميزات (Feature Flags) التي تشغّل ميزة أو توقفها، وترحيل قواعد البيانات وتغييرات الأنظمة المتصلة.

تحليل الأثر: اختيار ما تعيد تشغيله

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

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

• ما الذي تغيّر بالضبط: الشيفرة أم بنية البيانات أم الإعدادات أم إحدى الاعتماديات؟ يخبرك بذلك طلب الدمج (Pull Request)، أي التغيير الذي يقدّمه المطور للمراجعة، وقائمة الفروق (Diff) بالأسطر التي تغيّرت.
• من يستخدمه أيضاً: الشاشات أو الواجهات البرمجية أو التقارير أو المهام أو الخدمات التي تستدعي الدالة نفسها أو تقرأ الجدول نفسه. ومصفوفة التتبع (Traceability Matrix) تبيّن الاختبارات التي تغطي متطلباً تغيّر.
• ما البيانات المخزنة التي يمسّها: السجلات المحفوظة قبل التغيير يجب أن تبقى صالحة للعمل بعده.
• ما المناطق عالية المخاطر في كل الأحوال: الدفع وتسجيل الدخول وتصدير البيانات، والمناطق التي تعطلت بعد تغييرات مشابهة.

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

مثال تطبيقي: إصلاح في شيفرة فحص مشتركة

العيب BUG-2143: في صفحة الدفع تُرفض أرقام الجوال بالصيغة الدولية، مثل +966 50 000 1234، برسالة «رقم الجوال غير صالح». يصلح البناء ⁦3.4.2⁩ الدالة المشتركة normalizePhone(). وسؤال «من يستخدمها أيضاً؟» يبيّن أن التسجيل وتعديل الملف الشخصي وخدمة إرسال رموز OTP بالرسائل النصية تستدعيها كذلك.

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

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

BUG-2143 | build 3.4.2 | changed: normalizePhone() in shared validation

1. CONFIRMATION  (original steps, data and environment first)
   [ ] checkout with +966 50 000 1234        -> accepted, order placed
   [ ] 0500001234, 966500001234, with spaces -> accepted, saved as +966500001234
   [ ] +966 50 000 12 (too short)            -> still rejected

2. REGRESSION  (selected by impact analysis)
   changed area  phone field at checkout: all existing test cases
   dependents    sign-up, profile edit, OTP by SMS: same stored format
   stored data   customers saved before 3.4.2 still receive their OTP
   core          log in, search, card payment (critical journeys)
   left out      wishlist and reviews: they do not use phone numbers
   safety net    full regression suite in the scheduled nightly run

جرّبها: مقارنة استجابات API

لماذا تُؤتمت اختبارات الانحدار أولاً

تُشغَّل اختبارات الانحدار مرة بعد مرة، وتكبر حزمتها مع كل إصدار، لذلك يعدّ المنهج اختبار الانحدار مرشحاً قوياً للأتمتة وينصح بالبدء فيها مبكراً. ومع التكامل المستمر (Continuous Integration) تُشغَّل مع كل تغيير، وغالباً على عدة مستويات: اختبارات المكوّنات للمنطق، واختبارات API للخدمات، وعدد قليل من الرحلات الشاملة (End-to-End).

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

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

أسئلة شائعة

المراجع

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• ISTQB GlossaryISTQBالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
• ISO/IEC/IEEE 29119-1:2022 — Software and systems engineering — Software testing — Part 1: General conceptsISO/IEC/IEEE · 2022المعيار الدولي لاختبار البرمجيات: المفاهيم والعمليات والتوثيق والتقنيات.