الاختبار اليدوي مقابل الاختبار الآلي

نظرة عامة. تُؤتمت ستة فحوص: K1 (واجهة المستخدم)، وK2 وK3 وK4 (الواجهة البرمجية)، وK8 (واجهة المستخدم على شبكة متصفحات)، وK9 (نص برمجي للحمل). تجتاز الخمسة الأولى الأسئلة الثلاثة كلها؛ أما K9 فلا يعمل إلا قبل موعد محدد وبعد التغييرات الخطرة، لكن اختبار الحمل لا يمكن أداؤه يدوياً أصلاً، فيُؤتمت حالما تُحدَّد له نتيجة متوقعة متفق عليها. وتبقى أربعة مع الإنسان: K5 وK10 حكم، وK6 استكشافي، وK7 يعمل مرة واحدة. و«ليس بعد» هو الجواب عن أتمتة الحجز الجماعي: تنتظر حتى يصبح التصميم نهائياً (انظر K6). ويقرر هرم الاختبار المستوى: يعيش الفحص في أدنى مستوى يمكن التعبير عنه فيه، لذلك K2 وK3 وK4 اختبارات واجهة برمجية لا تحتاج إلى اختبار واجهة مستخدم، ولا يشغّل متصفحاً من الفحوص المؤتمتة إلا K1 وK8. وإن اختلف تصنيفك فراجعه مقابل الأسباب أدناه؛ فالاختيار المختلف مع سبب مكتوب مقبول، أما الفحص المؤتمت «لأن ذلك ممكن» فغير مقبول.

K1: يُؤتمت على مستوى واجهة المستخدم، بوصفه الرحلة الشاملة الوحيدة في خط الأنابيب. يعمل مع كل تغيير في GitLab CI وقبل كل إصدار (التكرار)، وينتهي بنتيجة محددة (تذكرة برمز QR للمقعدين المختارين)، ولا تتغير شاشات الحجز في هذا الإصدار فيما عدا خطوة الدفع (الاستقرار). وستتغير خطوة الدفع مرة واحدة في ⁦15⁩ أكتوبر: خطّط لهذه الصيانة ليوم التبديل (بطاقة اختبار المزوّد الجديد وشاشاته) بدلاً من وصف المسار بعدم الاستقرار. وأبقِ النص البرمجي مقتصراً على الرحلة؛ فالأسعار وحالة المقاعد والتوافر تُفحص في مستوى أدنى.

K2: يُؤتمت على مستوى الواجهة البرمجية، مع كل إيداع. فطلب دقيق واستجابة دقيقة ومواصفة OpenAPI للمقارنة هي الهدف المثالي للأتمتة، وتطبيقات الجوال تعتمد على هذا العقد، فأي حقل أُعيدت تسميته أو حُذف يعطّلها يوم نشره. يستغرق الفحص ثوانيَ ومكانه بجانب اختبارات الوحدة في GitLab CI.

K3: يُؤتمت على مستوى الواجهة البرمجية، مبنياً على البيانات، مع كل إيداع؛ وليس اختبار واجهة مستخدم، لأن الواجهة البرمجية تقرر السعر ولا يفعل تطبيق الويب سوى عرضه. واختبار الوحدة الذي يكتبه المطورون لحساب السعر مستوى صحيح بالقدر نفسه، لأنه أدنى مستوى يمكن التعبير فيه عن القاعدة. فالقاعدة PR-7 لم تتغير منذ سنتين (الاستقرار)، والسعر المتوقع دقيق (الحتمية)، ويُفحص مع كل إصدار (التكرار). والصفوف هي الحدود بين الفئات العمرية ونوعا اليوم، والأسعار بالريال: في يوم غير الثلاثاء، العمر ⁦2⁩ ← مجاناً بلا مقعد، و⁦3⁩ ← ⁦25.00⁩، و⁦12⁩ ← ⁦25.00⁩، و⁦13⁩ ← ⁦45.00⁩، و⁦64⁩ ← ⁦45.00⁩، و⁦65⁩ ← ⁦30.00⁩؛ وفي يوم الثلاثاء الأعمار نفسها ← مجاناً، ثم ⁦20.00⁩ للخمسة الباقية. وأضف صفوفاً عند أطراف اليوم بالمنطقة الزمنية للسينما: الاثنين ⁦23:59⁩، والثلاثاء ⁦00:00⁩، والثلاثاء ⁦23:59⁩، والأربعاء ⁦00:00⁩. وقبل كتابة هذه النتائج المتوقعة اسأل مالك المنتج عن معنى «الثلاثاء»: أهو يوم العرض أم يوم الحجز؟ وسجّل الإجابة؛ فالفحص الذي لا نتيجة متوقعة محددة له ليس جاهزاً للأتمتة.

K4: يُؤتمت على مستوى الواجهة البرمجية، في حالتين: المقعد المحجوز بينما يدفع عميل ثمنه يُرفض لعميل ثانٍ (طلبان متتاليان)، وحجزان للمقعد نفسه يُرسلان في اللحظة نفسها ينتهيان بنجاح واحد ورفض واحد بالضبط (مثلاً 201 Created و409 Conflict). والنتيجة محددة وإن لم يكن التوقيت كذلك، والفحص مهم مع كل إصدار لأن المقعد المحجوز مرتين يكلّف استرداداً للمبالغ وثقةً. ويدوياً، لا يستطيع مختبِران بمتصفحين أن يجعلا نقرتيهما تقعان في الملّي ثانية نفسها، فتنجح الحالة الثانية دون أن يُختبر التزامن فعلاً؛ وتوليد طلبات متزامنة أتمتة بحكم التعريف. شغّله ليلياً أو مع كل إيداع في خدمة الحجز.

K8: يُؤتمت على مستوى واجهة المستخدم، ليلياً وقبل كل إصدار، لا مع كل إيداع. فهو رحلة K1 نفسها تُعاد على المتصفحات الأربعة، على حاسوب مكتبي وعلى هاتف، عبر شبكة متصفحات (browser grid) بأجهزة حقيقية أو محاكاة: نص برمجي واحد وثماني تهيئات. ويدوياً ستكون الرحلة نفسها مكررة ثماني مرات كل أسبوعين، وهو عمل متكرر وحتمي، أي ما ترسله القاعدة بالضبط إلى الأتمتة؛ ولأن K1 مؤتمت بالفعل، فالتكلفة الإضافية تهيئة لا كود جديد. وهو أبطأ من بقية الحزمة، ولذلك لا يوقف كل إيداع.

K9: يُؤتمت، بنص برمجي للحمل يرسل طلبات HTTP الخاصة بخريطة المقاعد وصفحة الدفع دون متصفح؛ فاختبار الحمل أتمتة بحكم التعريف، إذ لا يمكن إنتاج ⁦2,000⁩ عميل الساعة ⁦10:00⁩ يدوياً. يعمل قبل ⁦24⁩ أكتوبر ثم بعد أي تغيير في كود حجز المقاعد أو الدفع، على بيئة Staging بحجم بيئة الإنتاج، لا على الإنتاج، ولا يعمل أبداً على نظام لا يملكه الفريق، كمزوّد الدفع، دون إذن مكتوب. وأعطه نتيجة متوقعة محددة قبل تشغيله، مثلاً زمن الاستجابة ونسبة الأخطاء اللذين يقبلهما الفريق لخريطة المقاعد ولصفحة الدفع؛ وإلا أنتج أرقاماً بلا حكم.

K5: يدوي مكتوب، مع كل إصدار، على هاتف حقيقي بالإعدادات المحلية العربية. فعبارتا «قابل للاستخدام» و«يُقرأ صحيحاً من اليمين إلى اليسار» حكمان لا قيمة متوقعة تُقارَنان بها، فيخفق الفحص في الحتمية. اكتب قائمة تحقق قصيرة (تسميات المقاعد مقروءة، وأرقام المقاعد بترتيبها نفسه في قاعة العرض، والمقعد المختار ظاهر، والسعر في مكانه الصحيح) ليكون الفحص قابلاً للتكرار. ويمكن لمقارنة لقطات الشاشة لاحقاً أن تحرس التخطيط من التغييرات غير المقصودة، لكنها تُظهر فقط أن شيئاً تغيّر؛ أما كون النتيجة قابلة للاستخدام فيبقى حكماً للإنسان.

K6: جلسة استكشافية محددة الوقت ومبنية على ميثاق، مثلاً: «استكشف الحجز الجماعي من ⁦6⁩ إلى ⁦20⁩ مقعداً، بما في ذلك تغيير المقاعد والدفع، لاكتشاف السلوك المربك أو المعطّل»، في جلسة من ⁦60–90⁩ دقيقة مع ملاحظات. فلا نتيجة متوقعة محددة بعد، إذ لا يزال السلوك المتوقع قيد الاكتشاف، والشاشات غير مستقرة؛ فهذه هي الجولة الأولى على ميزة جديدة، وهي التي يعطيها الدليل للإنسان. وعندما يصبح التصميم نهائياً، اكتب الحالات الجديرة بالحفظ وسلّم المستقر منها إلى الأتمتة، وغالباً رحلة حجز جماعي واحدة بجانب K1.

K7: لمرة واحدة، يدوياً أو باستعلام يُستخدم مرة ثم يُهمل، وليس في الحزمة. يعمل مرة واحدة في ⁦15⁩ أكتوبر، فيخفق في التكرار، والنص البرمجي سيكلّف أكثر من الفحص نفسه. ومع ذلك أدِّه بعناية: سجّل معرّفات الطلبات الـ ⁦1,214⁩ قبل التبديل، وقارن القائمة، لا العدد وحده، بعده، واحفظ النتيجة مع ملاحظات الإصدار.

K10: مراجعة يدوية مكتوبة، مع فصل الجزء الحتمي عنها. فكون الرسالة مفهومة وتخبر العميل بما يفعله لا يمكن مقارنته بقيمة متوقعة؛ يقرأ المختبِر كل رسالة في سياقها، بالإنجليزية والعربية، مرة مع كل إصدار أو كلما تغيّر نص. أما الجزء الحتمي فيذهب إلى الأتمتة: أن تعيد الواجهة البرمجية رمز الخطأ المتفق عليه (فحص واجهة برمجية بجانب K2)، وأن تعرض كل حالة خطأ رسالة أصلاً (خطوة في رحلة واجهة المستخدم بجانب K1).

السؤال Q1. تحل الأتمتة محل الانحدار اليدوي المكتوب، أي تكرار فحوص معروفة يدوياً، وينبغي أن تفعل: K1 وK2 وK3 وK8 هي ذلك بالضبط، أما K9 وحالة التزامن في K4 فلا يمكن أداؤهما يدوياً أصلاً. ولا تستطيع أن تحل محل الاختبار الاستكشافي (K6)، ولا الحكم على قابلية الاستخدام والتوطين (K5 وK10)، ولا مراجعة المتطلبات، لأن النص البرمجي لا يفحص إلا ما توقعه أحد حين كُتب. والفريق الذي يؤتمت كل شيء ينتهي بحزمة انحدار قوية وعدد متزايد من عيوب الإنتاج التي لم يكتب أحد نصاً لها. أما الوعد الواقعي فمختلف: حين تحرس الحزمة ما يعمل بالفعل مع كل تغيير، ينتقل وقت المختبِرين إلى ما قبلها: المتطلبات، والميزات الجديدة، والجلسات الاستكشافية.

السؤال Q2. الأول: الزمن من الإيداع إلى نتيجة الانحدار، وينبغي أن يكون دقائق وأن ينخفض: اليوم تجيب اختبارات الوحدة خلال ⁦4⁩ دقائق لكن حزمة واجهة المستخدم تجيب صباح اليوم التالي، فالمطور الذي يكسر صفحة الدفع يعرف ذلك بعد يوم. والثاني: حصة عيوب الإنتاج التي كان يمكن لفحص آلي موجود أن يلتقطها، وينبغي أن تنخفض مع الوقت؛ فإن بقيت مرتفعة فالحزمة لا تغطي ما يهم مهما كانت خضراء.

السؤال Q3. أصلح فحص خريطة المقاعد المتذبذب (Flaky) أو احذفه هذا الأسبوع: فالحزمة التي تحمرّ مرة في الأسبوع دون عطل فعلي تدرّب الفريق على تجاهل الأحمر، وكون أحد لا يعيد تشغيلها يدل على أن ذلك حدث فعلاً. وراجع الفحوص الـ ⁦38⁩ وانقل كل فحص لقاعدة عمل، أي الأسعار وحالة المقاعد والتوافر، من المتصفح إلى مستوى الواجهة البرمجية حيث يعمل في ثوانٍ؛ فالقاعدة المختبَرة على مستوى الواجهة البرمجية لا تحتاج إلى اختبار واجهة مستخدم. وأبقِ في حزمة واجهة المستخدم الرحلات التي يمكن أن تفشل في واجهة المستخدم فقط، بدءاً بـ K1 ثم الحجز الجماعي لاحقاً، لتعمل في دقائق مع كل تغيير في GitLab CI بدلاً من مرة كل ليلة؛ ولا يبقى ليلياً إلا التشغيل على المتصفحات المتعددة (K8). وراجع الحزمة بحثاً عن التكرارات والفحوص الميتة كل ربع سنة، وأعطِ مهندس الأتمتة بقية هذه القائمة بهذا الترتيب عملاً لشهره الأول.