الاختبارات الفاشلة والمحجوبة
يفشل الاختبار حين يُنفَّذ وتختلف النتيجة الفعلية عن النتيجة المتوقعة. ويكون محجوباً (Blocked) حين لا يمكن تنفيذه، أو لا يمكنه الوصول إلى الخطوة التي يفحصها، لأن شيئاً خارج الاختبار يعترض طريقه: عيب في خطوة سابقة، أو بيئة متوقفة، أو بيانات أو صلاحيات ناقصة. فإذا فشلت إضافة باقة (Bundle) إلى السلة، فإن اختبار إضافة الباقات يفشل، أما اختبار خصم الباقات، الذي يحتاج إلى باقة في السلة، فيكون محجوباً.
والنتيجة الفاشلة لا تُثبت بعدُ وجود عيب في المنتج: يصف منهج ISTQB تنفيذ الاختبار بأنه مقارنة النتائج الفعلية بالمتوقعة، ثم تحليل كل شذوذ (Anomaly) لمعرفة سببه المرجّح قبل الإبلاغ عنه.
لماذا يهم
الاختبار الفاشل الذي يُبلَّغ عنه خطأً على أنه عيب في المنتج يضيّع وقت المطور، ويُرفض، ويُفقد التقرير التالي شيئاً من الثقة. وصرف إخفاق حقيقي بقولك «إنها البيئة فقط» أسوأ: فالعيب يصل إلى المستخدمين.
وتحمل الاختبارات المحجوبة خطراً أخفى: فهي ليست ناجحة ولا فاشلة، والميزات التي خلفها لم تُختبر. وتشغيلٌ فيه 40 اختباراً ناجحاً و30 اختباراً محجوباً يقول عن الجودة أقل بكثير مما يوحي به عدد الناجح.
لماذا يفشل الاختبار: المنتج أم الاختبار أم البيئة
للفرق بين النتيجة الفعلية والمتوقعة ثلاثة مصادر محتملة: عيب في المنتج (البرنامج لا يتصرف كما يقول أساس الاختبار)، أو مشكلة في الاختبار (حالة الاختبار أو السكربت أو النتيجة المتوقعة أو التنفيذ خاطئ)، أو مشكلة في البيئة أو بيانات الاختبار (البناء أو الخدمات أو الإعدادات أو البيانات ليست كما يفترضها الاختبار). والمصدران الأخيران يُنتجان نتيجة إيجابية كاذبة (False positive) كما في درس الخطأ والعيب والإخفاق.
استبعد التفسيرات الأرخص أولاً، بهذا الترتيب. فالإخفاق الذي يجتاز الأسئلة الأربعة يُبلَّغ عنه عيباً في المنتج، والذي يجتاز الثلاثة الأولى ولا يتكرر يُبلَّغ عنه أيضاً مع وصفه بأنه متقطع.
- هل وصل الاختبار إلى الخطوة التي تفحص نتيجته المتوقعة؟ إن لم يصل فهو محجوب لا فاشل.
- هل كان البناء (Build) والخدمات والإعدادات والبيانات كما يحتاجها الاختبار؟ فالبناء الأقدم أو قسيمة أحادية الاستخدام سبق استعمالها تُفشل اختبارات كان المنتج سينجح فيها. ويتناول الدرس التالي، عن مشكلات البيئة وبيانات الاختبار، علاماتها وكيف تسجّلها.
- هل الخطوات والنتيجة المتوقعة صحيحة وفق المتطلب الحالي، وهل اتُّبعت كما كُتبت؟ فالاختبار الذي ما زال يتوقع «Checkout» بعد تغيير معتمد إلى «Pay now» هو الخاطئ لا المنتج.
- هل يتكرر الإخفاق حين تعيد إنتاجه كما في الدرس السابق؟ إن لم يتكرر فسجّله فاشلاً لا ناجحاً، وأبلغ عنه إخفاقاً متقطعاً (Intermittent) مع الأدلة ومعدل حدوثه.
الإجابة: لا
النتيجة: محجوبسجّله محجوباً مع رقم تذكرة العائق ومالكه، ونفّذه حين يزول العائق.تنبيهالإجابة: نعم
سؤال 2: هل كان البناء والخدمات والإعدادات والبيانات كما يفترضها الاختبار؟الإجابة: لا
النتيجة: مشكلة في البيئة أو بيانات الاختبارليست عيباً في المنتج. البيئة: سجّله محجوباً بتذكرة بيئة، وأبلغ مالكها، وأعد التشغيل بعد الإصلاح. بيانات الاختبار: أصلح البيانات أو أعد إنشاءها، واذكر السبب في النتيجة، وسجّل إعادة التشغيل تنفيذاً جديداً.الإجابة: نعم
سؤال 3: هل الخطوات والنتيجة المتوقعة صحيحة وفق المتطلب الحالي، وهل اتُّبعت كما كُتبت؟الإجابة: لا
النتيجة: مشكلة في الاختبارصحّح حالة الاختبار أو السكربت وفق أساس الاختبار، واذكر السبب، وأعد التشغيل.الإجابة: نعم
سؤال 4: هل يتكرر الإخفاق حين تعيد الاختبار؟الإجابة: لا
النتيجة: إخفاق متقطعسجّله فاشلاً مع الأدلة ومعدل حدوثه، وأبلغ عنه موصوفاً بأنه متقطع، ولا تسجّله ناجحاً أبداً.تنبيهالإجابة: نعم
النتيجة: عيب في المنتجسجّله فاشلاً، وأبلغ عن العيب مع الأدلة، واربطه بالاختبار.فشل
ترتيب للفحص لا قاعدة صارمة: إذا أشارت الأدلة بوضوح إلى سبب واحد فابدأ به.
الاختبارات المحجوبة: حين لا يصل الاختبار إلى فحصه
الاختبار المحجوب لم يُنتج أي نتيجة عن الشيء الذي يفحصه. ومن العوائق المعتادة: عيب في خطوة سابقة أو في ميزة يعتمد عليها الاختبار، أو خدمة متوقفة، أو بيانات أو صلاحيات ناقصة، أو ميزة لم تُنشر بعد.
والقاعدة: الإخفاق يُنسب إلى الاختبار الذي فشل فحصه هو، وكل اختبار آخر احتاج إلى تلك الخطوة يكون محجوباً بسببه. فإذا فشل تسجيل الدخول، فاختبار تسجيل الدخول فاشل واختبارات الدفع محجوبة. وتسجيلها كلها فاشلة يُظهر عيباً واحداً على أنه إخفاقات كثيرة، ويخفي أن تلك الميزات لم تُفحص أصلاً. وبعض الفرق تسجّلها فاشلة مع رابط إلى العيب بدلاً من ذلك؛ فاتفقوا على عُرف واحد.
- ابحث أولاً عن طريق صالح آخر، كإنشاء الطلب عبر الواجهة البرمجية (API)، واذكر أي حل بديل في النتيجة.
- حين يزول العائق تُنفَّذ الاختبارات المحجوبة للمرة الأولى. فهي ليست إعادة اختبار، وقد تكشف عيوباً كان العائق يخفيها، وهو حجب العيوب (Defect masking) الذي مرّ في درس الخطأ والعيب والإخفاق.
ماذا تسجّل لكل نتيجة
كلمة «فاشل» وحدها تُجبر غيرك على تكرار عملك.
- لكل نتيجة: معرّف حالة الاختبار، والتشغيل، والبناء، والبيئة، والمختبِر، والتاريخ.
- الفاشل: الخطوة التي فشلت، والنتيجة الفعلية بجوار المتوقعة، والأدلة (لقطة شاشة أو سجل أو استجابة)، وفئة السبب، ومعرّف العيب.
- المحجوب: ما الذي يحجبه وعند أي خطوة، ورقم تذكرة العائق ومالكه، ومنذ متى.
- مشكلة الاختبار: ما الخطأ، وكيف صُحّح ورُوجع، والنتيجة بعد التصحيح، مع رابط إلى أي تغيير في المتطلب.
- إعادة الاختبار: معرّف العيب، والبناء الذي يتضمن الإصلاح، والنتيجة وأدلتها، مسجّلةً تنفيذاً جديداً حتى يبقى الإخفاق الأصلي في السجل.
مثال تطبيقي: فرز تشغيل واحد لاختبارات الدفع
تُنفَّذ ستة اختبارات لعملية الدفع على البناء 4.12.0 في بيئة Staging، ولا ينجح خمسة منها في المرة الأولى. ويعرض السجل النتائج بعد الفرز.
- يفحص TC-206 إضافة باقة إلى السلة، فخطأ HTTP 500 (خطأ من جهة الخادم) هو إخفاقه هو: فاشل، والعيب DEF-480. أما TC-203 فيفحص خصم الباقات ويتوقف عند الخطوة 2: محجوب بالعيب DEF-480، وليس عيباً ثانياً.
- وصل TC-202 إلى فحصه في بيئة سليمة، وإجماليه المتوقع يتبع المتطلب، وتكرر الإخفاق: فاشل، عيب في المنتج DEF-482.
- توقف TC-204 عند الدفع: أعادت بيئة تجربة الدفع (Sandbox) التابعة لطرف ثالث الرمز 503 (الخدمة غير متاحة) لكل البطاقات، وفشل فحص سلامتها أيضاً. محجوب بتذكرة البيئة ENV-77، ولا عيب في المنتج.
- توقّع TC-205 أن يكون اسم الزر «Checkout»، لكن تغييراً معتمداً في التصميم كان قد غيّر اسم الزر إلى «Pay now»: مشكلة في الاختبار. فصُحّحت حالة الاختبار وفق ذلك التغيير، ومرّت بالمراجعة المعتادة لدى الفريق لتصبح TC-205 v2، ثم أعاد المختبِر تشغيلها مربوطةً بالتغيير: ناجح.
- الحصيلة: اختباران ناجحان، واثنان فاشلان، واثنان محجوبان، وتقريران عن عيبين بدلاً من خمسة تقارير.
Run: checkout regression, cycle 3 Build: 4.12.0 Environment: staging
Test Result Step Note Link
TC-201 Passed - - -
TC-202 Failed 4 10% coupon: total 115.00, expected 103.50 DEF-482
TC-203 Blocked 2 Cannot add bundle to cart (HTTP 500) DEF-480
TC-204 Blocked 5 Payment sandbox returns 503 for every card ENV-77
TC-205 Passed 3 Re-run after test fix: label is now "Pay now" TC-205 v2
TC-206 Failed 2 Adding a bundle to the cart returns HTTP 500 DEF-480إعادة الاختبار بعد الإصلاح
يتحقق اختبار التأكيد (Confirmation Testing)، أي إعادة الاختبار، من الإصلاح المُعلَن (انظر درس اختبار التأكيد واختبار الانحدار). فحين يُصلَح DEF-480 في البناء 4.12.1، يُعاد اختبار TC-206 ويُنفَّذ TC-203 للمرة الأولى. فإذا فشل TC-203 حينها في الخصم، فهذا عيب جديد كان العائق يخفيه، لا إعادة فتح للعيب DEF-480.
- تأكد أن البناء قيد الاختبار يتضمن الإصلاح (انظر العيب أو ملاحظات الإصدار)؛ فإعادة الاختبار على البناء القديم لا تثبت شيئاً.
- كرّر الخطوات والبيانات والظروف الأصلية مع بضعة تنويعات قريبة، كأنواع أخرى من الباقات، وسجّل إعادة الاختبار تنفيذاً جديداً.
- إذا نجحت فحدّث العيب كما تحدده دورة حياة العيب لديكم؛ وإذا فشلت بالطريقة نفسها فأعد فتحه بالبناء الجديد والأدلة؛ وإذا فشلت بطريقة مختلفة فأبلغ عن عيب جديد واربط بينهما.
- ثم نفّذ الاختبارات التي كان العيب يحجبها، واختبارات الانحدار المختارة لهذا التغيير.
أخطاء شائعة
- الإبلاغ عن كل اختبار فاشل على أنه عيب في المنتج دون التحقق أولاً من البيئة والبيانات والنتيجة المتوقعة.
- إلقاء اللوم على «البيئة» أو «التذبذب» دون دليل، أو تسجيل الاختبار ناجحاً بعد تشغيل ثانٍ نجح مصادفةً.
- تسجيل اختبارات فاشلة وهي لم تصل إلى فحصها أصلاً، فيبدو العيب الواحد إخفاقات كثيرة.
- إعادة الاختبار على بناء لا يتضمن الإصلاح، أو الكتابة فوق النتيجة الفاشلة الأصلية.
- تعديل النتيجة المتوقعة لتطابق ما يفعله المنتج أياً كان، دون الرجوع إلى المتطلب.
من منظور ضمان الجودة
افرز فور الإخفاق، ما دامت البيئة والبيانات على حالها، وابدأ بالفحوص الرخيصة: البناء، والخدمات، وحالة الاختبار مقابل المتطلب الحالي. وإن لم تتأكد فاسأل المطور والأدلة بين يديك. والفئة تخبرك مع من تتحدث: المطور، أو كاتب الاختبار، أو مالك البيئة، أو مالك المنتج حين يكون المتطلب غامضاً.
أبلغ عن الاختبارات المحجوبة في تقرير الحالة اليومي مجمّعةً حسب العائق: عبارة مثل «12 اختباراً للدفع محجوبة بالعيب DEF-480 منذ الثلاثاء» تتيح لقائد الاختبار أن يطالب بإصلاح واحد. وإذا هددت الاختبارات المحجوبة معايير الخروج فقل ذلك مبكراً، ليختار الفريق عن وعي: إصلاح العائق، أو تعديل الخطة، أو قبول المخاطرة.
تمرين عملي
افرز خمس نتائج من تشغيل لتطبيق حجز مواعيد
تنفّذ الدورة 2 لتطبيق حجز مواعيد عيادة على البناء 2.7.0، ولم تنجح خمسة اختبارات. صنّف كل ملاحظة: عيب في المنتج، أو مشكلة في الاختبار، أو مشكلة في البيئة أو البيانات، أو اختبار محجوب، أو إخفاق متقطع، واذكر النتيجة التي تسجّلها والإجراء التالي. ثم خطّط إعادة الاختبار حين يُصلَح عيب الحجز.
تطبيق حجز مواعيد العيادة، البناء 2.7.0، بيئة الاختبار، الدورة 2
TC-31 تسجيل مريض: لم تصل رسالة الترحيب بالبريد. صفحة حالة خدمة البريد
تُظهر أن خادم البريد التجريبي متوقف منذ الساعة 09:00.
TC-32 إلغاء حجز: لا يمكن البدء؛ الخطوة 1 (حجز موعد) تعرض
«الموعد غير متاح» لكل موعد شاغر.
TC-33 حجز موعد: «الموعد غير متاح» لكل موعد شاغر. تكرر 3 مرات مع طبيبين
ومستخدمين جدد. سجل الخادم: NullPointerException.
TC-34 قائمة الأطباء: المتوقع 8 أطباء، والمعروض 9. أضافت العيادة الطبيب
التاسع الأسبوع الماضي، واعتُمد ذلك في طلب التغيير CR-19.
TC-35 سجل الحجوزات: بعد الدخول بحساب المريض B ظهر حجز واحد للمريض A.
حدث مرة واحدة، ولم يتكرر في 5 محاولات.إظهار الإجابة النموذجية
TC-31: مشكلة في البيئة، لا عيب في المنتج. خادم البريد المتوقف لا يقول شيئاً عن التسجيل: سجّل الاختبار محجوباً بتذكرة بيئة، وأبلغ مالكها، وأعد تشغيله لاحقاً.
TC-33: عيب في المنتج. وصل إلى فحصه، ويُظهر سجل الخادم استثناءً (Exception) في التطبيق لا توقفاً في البيئة، ونتيجته المتوقعة تتبع المتطلب، ويتكرر مع أطباء ومستخدمين آخرين. سجّله فاشلاً وأبلغ عنه، وليكن DEF-501، مع الخطوات والرسالة وسطر السجل والبناء.
TC-32: محجوب بالعيب DEF-501، لأن الحجز، وهو فحص TC-33، يفشل. وتقرير ثانٍ لن يكون إلا نسخة مكررة من DEF-501.
TC-34: مشكلة في الاختبار. المنتج يتبع CR-19: حدّث حالة الاختبار إلى 9 أطباء، واربطها بـCR-19، وأخضع التعديل للمراجعة المعتادة لحالات الاختبار لدى الفريق، ثم أعد تشغيلها وسجّل النتيجة بعد التصحيح.
TC-35: إخفاق متقطع لا يجوز إهماله: رؤية حجز مريض آخر مشكلة خصوصية ولو حدثت مرة واحدة. سجّله فاشلاً مع لقطة الشاشة والوقت والحسابين والمحاولات الخمس التي لم تكرره، وأبلغ عنه على أنه متقطع، وأخبر المطور الآن.
إعادة الاختبار: حين يُصلَح DEF-501، تأكد أن البناء يتضمن الإصلاح، وأعد اختبار TC-33 تنفيذاً جديداً مع الأطباء أنفسهم وأطباء آخرين، وحدّث DEF-501؛ ثم نفّذ TC-32 للمرة الأولى، واختبارات الانحدار المختارة.
أسئلة شائعة
من يرفع العائق عن الاختبار المحجوب، وإلى متى يمكن أن يبقى محجوباً؟
يرفعه مالك العائق: المطور إن كان عيباً، ومالك البيئة إن كانت خدمة متوقفة، ومن يمنح الصلاحيات إن كانت صلاحية ناقصة. ودورك أن تسجّل رقم تذكرة العائق ومالكه ومنذ متى، وأن تبحث عن طريق صالح آخر، وأن تبلّغ عن الاختبارات المحجوبة في تقرير الحالة اليومي مجمّعةً حسب العائق. ولا توجد مدة ثابتة: فحين تهدد الاختبارات المحجوبة معايير الخروج أخبر قائد الاختبار، ليختار الفريق إصلاح العائق أو تعديل الخطة أو قبول المخاطرة.
ماذا لو لم أستطع الحسم بين عيب في المنتج ومشكلة في الاختبار؟
ارجع إلى أساس الاختبار. إذا كان المتطلب أو معايير القبول أو تغيير معتمد يحدد ما يجب أن يحدث، فقارن به. وإذا كان أساس الاختبار صامتاً أو متناقضاً، فاسأل مالك المنتج أو محلل الأعمال، وسجّل الإجابة في حالة الاختبار قبل أن تبلّغ عن أي شيء.
هل يمكنني إعادة تشغيل الاختبار الفاشل حتى ينجح؟
لا. النجاح في المحاولة الثانية لا يلغي الإخفاق الأول. سجّل النتيجتين، وتعامل مع الاختبار على أنه متقطع، وحقّق فيه؛ فالإخفاق المتقطع في المنتج، كمشكلة توقيت، يظل عيباً.
المراجع
- ISTQB Certified Tester Foundation Level (CTFL) v4.0المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
- ISTQB Glossaryالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
- ISO/IEC/IEEE 29119-2:2021 — Software and systems engineering — Software testing — Part 2: Test processesنموذج عمليات الاختبار: العمليات المؤسسية وعمليات إدارة الاختبار وعمليات الاختبار الديناميكي، مع أنشطتها ومخرجاتها.
تدرّب بأدوات متقن
قارن نصّين سطراً بسطر أو كلمةً بكلمة مع إبراز الاختلافات.
مقارنة مستندي JSON دلالياً وإبراز القيم المضافة والمحذوفة والمتغيرة.
افحص عدة نقاط نهاية لصحة API دفعة واحدة واحصل على الحالة وزمن الاستجابة وملخّص نجاح/فشل.
قارن استجابتي API (مثل بيئة التجريب مقابل الإنتاج) واحصل على قائمة بكل فرق بنيوي أو في القيم.
ولّد سيناريوهات اختبار الانحدار من وصف التغيير وقائمة الوحدات المتأثرة والمرتبطة.
للتعمّق أكثر
تقدّمك في هذا الموضوع
سجّل الدخول لتتابع تقدّمك
علّم الموضوعات مكتملة، وتابع من حيث توقفت، وافتح امتحانات التخصص.