مشكلات البيئة وبيانات الاختبار

لماذا يهم

في منهج ISTQB للمستوى التأسيسي يشمل تنفيذ الاختبار تحليل كل شذوذ (Anomaly) لمعرفة سببه المرجّح، والشذوذ المُبلَّغ عنه قد يتبيّن أنه نتيجة إيجابية كاذبة (False-positive result) لا عيبٌ حقيقي. ومشكلات البيئة وبيانات الاختبار من الأسباب المعتادة لهذه النتائج الإيجابية الكاذبة، وقد تُنتج أيضاً نتائج سلبية كاذبة (False negatives)، فينجح الاختبار مع أن العيب موجود.

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

مشكلات البيئة وعلاماتها

قد تتعطل أثناء التنفيذ أي طبقة من طبقات البيئة التي وصفها درس بيئات الاختبار، ولكل عطل علامات معتادة.

• بناء خاطئ: نشرٌ قديم أو ناقص؛ يعود عيب سبق إصلاحه، أو يختلف الإصدار المُعلَن عن بناء التشغيل.
• اعتمادية متوقفة: قاعدة بيانات أو طابور رسائل أو بيئة تجربة الدفع (Sandbox) أو بديل الرسائل القصيرة (Stub) غير متاح. فتظهر في ميزات لا علاقة بينها أخطاء اتصال وانتهاء مهلة (Timeout) أو رموز حالة HTTP ⁦502⁩ (بوابة سيئة) و⁦503⁩ (الخدمة غير متاحة) و⁦504⁩ (انتهاء مهلة البوابة)؛ وبهذه الرموز يقول الخادم إنه، أو خدمة خلفه، لا يستطيع الإجابة إجابة سليمة الآن.
• انحراف الإعدادات (Configuration drift): علم ميزة (Feature flag) أو متغير بيئة أو عنوان خدمة يختلف عمّا تفترضه الاختبارات، فتغيب ميزة أو تتصل بنظام خاطئ.
• صلاحية وصول منتهية: كلمة مرور حساب اختبار، أو رمز وصول API (Token)، وهو المفتاح الذي يستخدمه نظام لاستدعاء نظام آخر، أو شهادة TLS الخاصة بالبيئة، وهي ما يتيح للمتصفحات الاتصال عبر HTTPS؛ فتُرفض طلبات كانت تعمل بالأمس برمز ⁦401⁩ (غير مُصادَق عليه)، أو يفشل تسجيل الدخول، أو ترفض المتصفحات الاتصال بتحذير من الشهادة.
• الموارد والتداخل: قرص ممتلئ، أو اتصالات قاعدة بيانات مستنفدة، أو شخص يعيد نشر البيئة المشتركة في منتصف تشغيلك؛ فيبدأ الفشل في منتصف التشغيل، أو يفشل كل شيء بضع دقائق ثم يعود إلى طبيعته.

جرّبها: فاحص صحة API جرّبها: مرجع رموز حالة HTTP جرّبها: فاحص انتهاء صلاحية JWT

مشكلات بيانات الاختبار وعلاماتها

كثير من الشروط المسبقة في حالة الاختبار يتعلق بالبيانات: العميل C-101 موجود، والطلب مدفوع ولم يُشحن. ومشكلة البيانات تعني أن شرطاً مسبقاً من هذا النوع لم يكن متحققاً حين نُفِّذ الاختبار، مع أن المنتج ربما تصرّف تصرّفاً صحيحاً.

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

• مفقودة: لم يُشغَّل سكربت تهيئة البيانات (Seed script)، أو لم يُستعَد خط الأساس بعد تحديث البيانات.
• في حالة خاطئة: استخدم السجلَّ اختبارٌ آخر أو مختبِر آخر، فصار الطلب مُستردّاً أو الحساب مقفلاً.
• تصادمات: تتشارك تشغيلات متوازية حساباً واحداً، أو تظهر رسالة «البريد الإلكتروني مسجّل مسبقاً» لأن تشغيلاً سابقاً ترك مستخدمه خلفه.
• قديمة: انتهت صلاحية تاريخ مكتوب بقيمة ثابتة أو قسيمة أو بطاقة اختبار، أو لم تعد نسخة من البيانات أُخذت قبل أشهر تطابق الأسعار أو الإعدادات الحالية.

جرّبها: مولّد UUID

التمييز بينها وبين عيوب المنتج

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

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

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

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

مثال تطبيقي: ⁦14⁩ اختباراً فاشلاً في صباح واحد

بحلول الساعة ⁦09:40⁩ فشل ⁦14⁩ اختباراً من أصل ⁦40⁩ في تشغيل انحدار إتمام الشراء على البناء ⁦4.1.0⁩. وبدلاً من كتابة ⁦14⁩ تقرير عيب، يجمّع المختبِر الاختبارات الفاشلة حسب العَرَض والتوقيت، ثم يفحص كل مجموعة.

تصيب حالات فشل الواجهة البرمجية (API) التسع نقاطَ نهاية (Endpoints) لا علاقة بينها، وكلها بالرمز ⁦401⁩ (غير مُصادَق عليه) نفسه منذ أول طلب في الساعة ⁦09:00⁩، وهذا يشير إلى صلاحية الوصول لا إلى ميزة بعينها. ويُظهر فكّ رمز الوصول (Token) الذي يستخدمه عميل الاختبار أن صلاحيته انتهت عند منتصف الليل: مشكلة بيئة واحدة، وحين جدّد مالك البيئة الرمز نجحت إعادة تشغيل الاختبارات التسعة كلها. واختبارات القسيمة استخدمت قسيمة لها تاريخ انتهاء ثابت قد مضى. والطلب الذي استخدمه اختبار الاسترداد كان تشغيلٌ آخر قد استردّ مبلغه مسبقاً، وهذا يفسّر الفشل لكنه لا يفسّر خطأ الخادم (HTTP ⁦500⁩)، فذلك عيب قائم بذاته. ولا يتكرر ببيانات جديدة في بيئة سليمة إلا فشل ضريبة القيمة المضافة.

النتيجة: مشكلة بيئة واحدة نجحت اختباراتها التسعة عند إعادة تشغيلها بعد تجديد الرمز، وإصلاحان للبيانات نجحت بعدهما إعادة التشغيل، وتقريرا عيب بدلاً من ⁦14⁩ تقريراً.

Run: Checkout regression / build 4.1.0 / test environment / 09:00-09:40
Not passed: 14 of 40 (before triage)

API-01..09  401 Unauthorized from cart, address and order endpoints alike
            test client's API token expired at 00:00     -> ENV-31, renewed, reruns passed
CPN-01..03  "Coupon expired"
            coupon in the data has a fixed end date      -> data fixed, rerun passed
RFD-04      500 error when refunding order O-7781
            O-7781 refunded by another run at 08:50      -> data reset, rerun passed
            a refunded order needs a clear message       -> defect DEF-436
TOT-02      VAT calculated on the price before discount
            same result on a fresh order, healthy env    -> defect DEF-437

الوقاية: افحص الإعداد قبل الاختبارات

يجعل منهج ISTQB للمستوى التأسيسي بناء بيئة الاختبار والتحقق من صحة إعدادها جزءاً من تهيئة الاختبار (Test implementation) قبل التنفيذ، ويذكر توافر البيئات وبيانات الاختبار ضمن معايير الدخول المعتادة؛ ويصف المعيار ISO/IEC/IEEE ⁦29119-3⁩ تقارير جاهزية لكليهما. ويذكر مقال Martin Fowler عن عدم الحتمية في الاختبارات غيابَ العزل والخدمات البعيدة والوقت بين الأسباب المعتادة للنتائج غير الموثوقة. والعادات التالية تستهدف هذه الأسباب.

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

جرّبها: مصنع بيانات الاختبار

أسئلة شائعة

المراجع

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• ISTQB GlossaryISTQBالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
• ISO/IEC/IEEE 29119-3:2021 — Software and systems engineering — Software testing — Part 3: Test documentationISO/IEC/IEEE · 2021نماذج ومحتوى وثائق الاختبار — سياسة الاختبار واستراتيجيته وخطته وتقارير الحالة والإنجاز وتقارير الحوادث.
• Eradicating Non-Determinism in Tests (Martin Fowler)martinfowler.com · 2011لماذا تُفقد الاختبارات المتذبذبة الحزمةَ قيمتها، وأسبابها الشائعة (العزل وعدم التزامن والخدمات البعيدة والوقت وتسرّب الموارد)، والحجر كاستجابة.