أين نكتشف الخلل بأقل التباس؟

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

الاختبار المبكر لا يعني تنفيذ كل الحالات مبكرًا؛ يعني وضع السؤال عند أرخص موضع يكشفه بوضوح. غموض كلمة «اليوم السابق» يعالج بمراجعة المتطلب. خطأ عامل المقارنة `<` بدل `<=` أو العكس يُعزل في اختبار مكوّن حول الحد. ضياع إزاحة الوقت بين الواجهة والخدمة يحتاج اختبار تكامل. واختفاء زر الإلغاء من واجهة المستخدم على الرغم من سماح الخدمة يحتاج فحص نظام. قد يظهر العطل في فحص نظام شامل، لكن تشخيص سببه يكون أبطأ لأن عدة طبقات تشارك. لذلك نبدأ بفحوص دقيقة ثم نضيف أدلة تربط الطبقات، دون افتراض أن كثرة اختبارات الواجهة تعوض طبقة مفقودة.

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