Smoke و Sanity و Regression — الفرق ومتى تستخدم كل واحد

نزلت نسخة جديدة الساعة 10، والفريق عندك بيسأل: «نبلّش اختبار كامل؟». الجواب المحترف مش «نعم» ولا «لأ» — الجواب: أي نوع اختبار، وليش هلأ.

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

الثلاثة بجملة

Smoke Testing — هل النسخة تستاهل اختبار؟

اختبار سطحي وسريع وعريض على المسارات الأساسية بعد كل build جديد، هدفه سؤال واحد: هل هذي النسخة مستقرّة كفاية لنبدأ الاختبار الحقيقي؟

بيمشي أفقياً على كل الوظائف الرئيسية بلا عمق: التطبيق يفتح؟ تسجيل الدخول يشتغل؟ الشاشة الرئيسية بتحمّل؟ الحفظ بيحفظ؟

مدّته المفروضة: من 10 لـ 30 دقيقة. إذا فشل، النسخة تُرفض وترجع للفريق التقني — بلا ما تضيّع يوم اختبار على build مكسور.

Sanity Testing — هل هذا الإصلاح ضبط فعلاً؟

اختبار ضيّق وعميق على منطقة محدّدة بعد إصلاح أو تعديل صغير، هدفه سؤال واحد: هل التعديل المطلوب صار صح، وهل منطقته لسا سليمة؟

مثال: انصلح Bug باحتساب الخصم. الـ Sanity Testing بيغطّي الخصم بحالاته (نسبة، مبلغ ثابت، صفر، أكبر من السلة) ومنطقة الحساب حواليه — بلا ما يلمس تسجيل الدخول والإشعارات.

مدّته المفروضة: دقايق لساعة، حسب المنطقة.

Regression Testing — شو انكسر بسبب التعديل؟

اختبار للتأكّد إنّ التعديلات الجديدة ما خرّبت شي كان يشتغل. هذا هو الاختبار الأوسع والأغلى، وبيغطّي الوظائف اللي ما تعدّلت أصلاً — لأنّها هي اللي بدنا نتأكّد إنّها لسا سليمة.

بيتنفّذ قبل الإصدارات، وبعد التعديلات الكبيرة، وبعد دمج فروع كبيرة، وبعد ترقية مكتبة أو إصدار نظام تشغيل جديد.

جدول المقارنة

	Smoke	Sanity	Regression
السؤال	النسخة تستاهل اختبار؟	هذا الإصلاح ضبط؟	شو انكسر بسبب التعديل؟
النطاق	عريض وسطحي	ضيّق وعميق	عريض وعميق
التوقيت	بعد كل build	بعد إصلاح أو تعديل صغير	قبل الإصدار وبعد التعديلات الكبيرة
المدة	10–30 دقيقة	دقايق لساعة	ساعات لأيام
موثّق بحالات اختبار؟	نعم، مجموعة ثابتة صغيرة	غالباً لأ (استكشافي موجّه)	نعم، Regression Suite
مناسب للأتمتة؟	نعم — أول شي تؤتمته	جزئياً	نعم — أعلى مردود للأتمتة
نتيجة الفشل	ترفض النسخة	ترجّع الـ Bug مفتوح	تفتح Bugs انحدار جديدة

مثال: إصدار واحد يمشي على الثلاثة

السياق: بوابة ويب، الإصدار 2.4، فيه ميزة جديدة «تصدير التقرير PDF» + إصلاح لBug بالبحث.

1. Smoke (الساعة 10:15، 20 دقيقة): البوابة تفتح، تسجيل الدخول يشتغل، لوحة المؤشرات تحمّل، صفحة التقارير تفتح، الخروج يشتغل. ✅ النسخة مقبولة للاختبار.
2. Sanity (الساعة 10:40): الـ Bug المُصلَح بالبحث — بحث بكلمة عربية، بكلمة إنجليزية، بنص كلمة، بحقل فاضي، بمسافات زايدة. ✅ الإصلاح ضبط.
3. اختبار الميزة الجديدة (باقي اليوم): تصدير PDF بحالاته — تقرير فاضي، تقرير طويل، أسماء عربية، أحرف خاصّة، تصدير مرّتين بسرعة.
4. Regression (اليوم التالي): المسارات اللي ما لمسناها — إنشاء مستخدم، رفع مرفقات، الإشعارات، الطباعة، الصلاحيات. ❌ لقينا إنّ زر «طباعة» صار يفتح صفحة فاضية → Bug انحدار (regression bug)، وهو أخطر أنواع الـ Bugs لأنّه بيمسّ شي كان شغّال.

هذا الترتيب هو اللي بيوفّر وقت: ما تبدأ اختبار عميق على build ممكن يُرفض، وما تعمل Regression كامل على كل إصلاح صغير.

Retesting مش Regression — فرق لازم يكون واضح

بيتخلطوا كثير، والفرق سهل:

• Retesting (إعادة الاختبار): تنفيذ نفس الحالة اللي فشلت، على النسخة اللي فيها الإصلاح — للتأكّد إنّ الـ Bug انصلح. حالات محدّدة سلفاً، ما بتنفع للأتمتة الأولى.
• Regression: تنفيذ حالات ثانية ما فشلت، للتأكّد إنّها لسا ناجحة.

بالعملي: الـ Bug انصلح؟ اعمل Retesting للحالة الفاشلة، وبعدها Regression للمسارات المرتبطة.

كيف تبني Regression Suite ما بينفجر بالحجم

أكبر مشكلة بالـ Regression إنّه بيكبر مع كل إصدار لحد ما يصير غير قابل للتنفيذ. الحل مش إنّك تختبر أقل — الحل ترتيب:

1. ابدأ من المسارات اللي بتوجع: تسجيل الدخول، الدفع/العملية الأساسية، الحفظ، الصلاحيات، وأي شي مربوط بالمال أو البيانات.
2. أضف كل Bug انحدار سابق: أي Bug رجع مرّتين، حالة اختباره بتصير عضو دائم بالـ Suite.
3. رتّب بمستويات: Regression-Core (ينفّذ كل إصدار)، و Regression-Full (ينفّذ قبل الإصدارات الكبيرة أو شهرياً).
4. احذف بلا خوف: حالات لميزات محذوفة أو مسارات ما حدا يستخدمها = وزن زايد.
5. أتمِت الأثقل والأكثر تكراراً: Smoke أول، وبعده Regression-Core — هدول أعلى مردود للأتمتة.
6. حدّد ميزانية وقت: «Regression-Core لازم يخلص بـ 4 ساعات». الميزانية بتفرض الترتيب.

أخطاء شائعة

• الادّعاء إنّ Smoke = Sanity. بأغلب الفرق العملية Smoke لكل build (عريض) و Sanity لكل إصلاح (ضيّق). لو فريقك بيسمّيهم غلط، اتفقوا على المعنى واكتبوه بالـ قاموس المصطلحات.
• Regression بلا مجموعة موثّقة. «رح نعيد اختبار كل شي» بيتحوّل بالتطبيق لـ «رح نختبر اللي بنتذكّره».
• تنفيذ Regression كامل على كل إصلاح. مكلف ومحدا رح يكمّله. Sanity + Regression-Core بيكفي بأغلب الحالات.
• إهمال Regression بعد ترقية بيئة أو مكتبة. كثير Bugs انحدار بتيجي من هون، مش من كود الفريق.

أسئلة شائعة

Smoke ولا Sanity أول؟ Smoke أول وعلى مستوى النسخة كلها. Sanity بعدها وعلى مستوى الإصلاح.

هل Smoke Testing لازم يكون مؤتمت؟ مش لازم، بس هو أفضل مرشّح للأتمتة: قصير، ثابت، وبينفّذ بعد كل build. ابدأ من هون لو بدك تبلّش أتمتة.

Regression شغل المختبر ولا الفريق؟ الفريق كله. المختبر بيبني ويحدّد الـ Suite، والأتمتة بتنفّذ الجزء المتكرّر، والفريق بيتفق على معايير القبول.

قد إيش حالة كافية للـ Smoke؟ بأغلب المشاريع بين 15 و 40 حالة تغطّي كل وظيفة رئيسية بمسار واحد سعيد. المعيار الحقيقي هو الوقت: لو صار أطول من نصّ ساعة، هذا مش Smoke.

هذا بيتسأل بامتحان ISTQB؟ نعم — أنواع الاختبار و Confirmation Testing و Regression Testing جزء أساسي من منهج CTFL.

خطوتك الجاية

• ثبّت الأساس: الفرق بين QA و QC و Testing.
• افهم دورة الاختبار كاملة: STLC من التخطيط للإغلاق.
• اكتب حالات الـ Suite صح: كيف تكتب حالة اختبار فعّالة.
• الأساسيات كاملة بالعربي: دورة ISTQB CTFL V4.