في العام الماضي بلغ فريقٌ عملتُ معه نسبة تغطية اختبارات قدرها 92%، فأقام احتفالاً صغيراً. وبعد ثلاثة أسابيع، تسبّب خطأ تقريب (rounding) في خدمة الفوترة لديهم بتحصيل مبالغ زائدة من نحو 4,000 عميل على مدى ستة أيام، قبل أن تكشفه تذكرة دعم فني. كل سطرٍ حمل ذلك الخطأ إلى الإنتاج كان «مُغطّى». لقد أثبتت الاختبارات أن الشيفرة تعمل، لا أنها صحيحة.
التغطية هي المؤشر الذي يستطيع الجميع حسابه، ولا ينبغي لأحدٍ أن يقدّسه. فهي تخبرك بالأسطر التي جرى تنفيذها أثناء تشغيل الاختبار، لكنها لا تقول شيئاً عمّا إذا كانت تأكيداتك (assertions) ذات معنى، ولا عمّا إذا كان الاختبار سيمسك بانحدارٍ (regression) فعلاً، ولا عمّا إذا كان ما بنيته هو ما احتاجه المستخدم بالفعل. أدِر الجودة برقم تغطيةٍ واحد، فتُحسّن المؤشّر بدلاً من المحرّك.
لماذا يكذب رقم التغطية
تجيب التغطية عن سؤالٍ ضيّق واحد: هل نُفِّذ هذا السطر؟ بإمكان الاختبار أن يستدعي دالّةً دون أن يؤكّد شيئاً ذا قيمة، ويبقى السطر أخضر رغم ذلك. راجعتُ حِزم اختبارات تقف عند 85% ونصف اختباراتها بلا تأكيدات ذات معنى — إذ كانت تكتفي بالتحقّق من أن الشيفرة لا ترمي استثناءً، وهذا معيارٌ بالغ التساهل.
ثم يأتي فخّ الهدف. وما إن تصبح تغطية الـ80% بوّابةً للدمج (merge gate)، حتى يكتب المهندسون اختباراتٍ لبلوغ الـ80% لا لاصطياد العلل. فتنتهي إلى اختبارات لدوال getter تافهة، وحالاتٍ حافّة غير مُختبَرة في منطق الدفع المعقّد، لأن الأسطر السهلة أرخص تغطيةً. يرتفع الرقم، ولا تنخفض المخاطرة.
التغطية تخبرك بما اختبرته، لا بجودة اختبارك له. والتغطية العالية بتأكيداتٍ هزيلة ليست سوى ثقةٍ لم تكسبها.
مؤشرات تتنبّأ بالجودة فعلاً
المؤشرات الجديرة بالمتابعة تشترك في صفةٍ واحدة: أنها تقيس النتائج والسلوك، لا النشاط. وإليك بعض ما أعتمد عليه في مشاريعي:
- معدّل تسرّب العيوب (defect escape rate) — نسبة العلل المكتشَفة في الإنتاج مقابل تلك المكتشَفة قبل الإصدار. وهو أقرب ما يملكه ضمان الجودة إلى نجمٍ يهتدي به. واتّجاهه نحو الانخفاض يعني أن شبكة الأمان تلتقط الأخطاء فعلاً.
- درجة الطفرة (mutation score) — يُخرّب اختبار الطفرات (mutation testing) شيفرتك عمداً (يقلب
<إلى>، ويعكس قيمةً منطقية) ثم يتحقّق ممّا إذا كان أيّ اختبارٍ سيفشل. فإن نجت اختباراتك من هذا التخريب، فهي لا تختبر شيئاً يُذكر. وهو الجواب الصادق عن سؤال: «هل تأكيداتي حقيقية؟» - معدّل فشل التغيير (change failure rate) وزمن الاستعادة (MTTR) — وهما مأخوذان مباشرةً من أبحاث DORA: ما نسبة عمليات النشر التي تُحدث عطلاً، وكم يستغرق تعافيك منه. وكلاهما يربط الجودة بالتسليم، حيث ينبغي أن تكون.
- معدّل الاختبارات المتذبذبة (flaky tests) — نسبة الاختبارات التي تنجح وتفشل دون أيّ تغيير في الشيفرة. فالاختبارات المتذبذبة تُعوّد فريقك على تجاهل البناء الأحمر، وهذا ما يقوّض بهدوءٍ كل ضوابط الجودة الأخرى لديك.
لاحظ أن أياً منها ليس سهل التلاعب به. فلا يمكنك اصطناع معدّل تسرّبٍ منخفض بكتابة اختباراتٍ جوفاء.
المؤشرات القائدة تتفوّق على المتأخّرة
معدّل التسرّب صادقٌ لكنه بطيء — فأنت تعرف بالفجوة بعد أن يعرفها مستخدموك. والرافعة الحقيقية أن تُركّب أدوات القياس في مرحلةٍ أبكر. فدرجة الطفرة وكثافة التأكيدات مؤشراتٌ قائدة (leading): تخبرك اليوم إن كانت الاختبارات التي تكتبها ستصمد. اقرنها بإشارات مرحلة المراجعة — كم عيباً تلتقطه مراجعة الشيفرة، وكم يبقى الـPR معلّقاً، وما متوسط حجم التغيير. فالتغييرات الأصغر والأسرع أقلّ فشلاً. وليس هذا من قبيل الحكايات الشائعة؛ بل هو من أكثر ما رسّخته بيانات DORA.
وليس المقصود تتبّع كل شيء. بل اختر مؤشرين أو ثلاثة تنطبق على نمط فشلك الفعلي. فالفريق الذي يغرق في حوادث الإنتاج ينبغي أن يراقب معدّل التسرّب وMTTR. أما الفريق الذي يعتمد على حزمة اختباراتٍ منتفخة يثق بها دون أن تكون مُختبَرةً فعلياً، فينبغي أن يُشغّل اختبار الطفرات ليكتشف كم من ذلك الأخضر حقيقي.
من أين تبدأ صباح الاثنين
لا تتخلَّص من أدوات التغطية — بل أنزلها فقط من رتبة الهدف إلى رتبة حاجز الحماية (guardrail). ثم أضِف إشارةً واحدة تقيس ما إذا كانت اختباراتك تعمل فعلاً. وخطوتي الأولى المعتادة: أُشغّل أداة اختبار طفرات على أكثر وحداتك حرجاً — الفوترة، أو المصادقة، أو أيّ شيءٍ قد يتصدّر عناوين الأخبار إن تعطّل — ثم أنظر إلى الناجين. فالطفرات التي تبقى حيّةً رغم حزمتك خريطةٌ دقيقة للمواضع التي تكتفي فيها اختباراتك بالتمثيل.
اختر المؤشر الوحيد الذي كان كفيلاً بالتقاط آخر علّة إنتاجٍ مؤلمة مررت بها، وابدأ بقياسه هذا الأسبوع.