كل فريق نلتقي به في هذا الموقف يعيش على التقويم نفسه. يحلّ يوم الإصدار، وخلال ساعات قليلة يشتعل طابور الدعم: مسار دفع توقّف فجأة عن قبول العمليات، تقرير يظهر فارغاً، صلاحية فتحت باباً ما كان ينبغي أن يُفتح أبداً. يخرج الإصلاح في تلك الليلة، ثم ينكسر شيء آخر في الأسبوع التالي. الشركة التي نتحدث عنها هنا عاشت داخل هذا الإيقاع مدةً طويلة، حتى لم يعد الأمر يبدو أزمةً، بل صار أشبه بحالة الطقس — مجرد مناخٍ تعمل بداخله.
لم يكونوا بحاجة إلى مزيد من البطولات الليلية؛ كان لديهم ما يكفي منها. ما كان ينقصهم هو وسيلة تجيب عن سؤال بسيط قبل الإطلاق: هل هذا الإصدار يعمل فعلاً؟
المشهد الذي وجدناه
كان العميل شركة B2B SaaS يعمل بها نحو أربعين شخصاً، بمنتجٍ واحد وقاعدة عملاء تضاعفت تقريباً خلال عام. كان فريق الهندسة قرابة عشرة إلى اثني عشر مطوّراً. لم يكن هناك فريق QA مخصّص؛ إذ كان الاختبار هو ما يستطيع أحد المطوّرين إنجازه في مساء اليوم السابق للإصدار، يتنقّل عبر التطبيق على جهازه الخاص ويأمل أن يكون كل شيء سليماً. نجح هذا الأسلوب حين كان المنتج صغيراً والفريق يعرف كل زواياه عن ظهر قلب، لكنه لم يصمد أمام التوسّع، وتجاوزه النمو بهدوء.
المشكلة الحقيقية
من السهل تصنيف الأمر على أنه "نقص في الأدوات"، لكن هذا التوصيف غير دقيق. المشكلة الأعمق أن أحداً لم يكن قادراً على الإجابة عن ذلك السؤال البسيط بأي قدر من الثقة. كان اختبار الـ regression اليدوي يستغرق ما يقارب الأسبوع، ولذلك كان يُتجاوَز عملياً. ومن دون شبكة أمان، تحوّل كل تغيير إلى رهانٍ صغير في العتمة. ولأن الإصدار كان يبدو خطِراً، صار الفريق يجمّع التغييرات دفعةً واحدة ويُطلق بوتيرة أقل — ما جعل كل إصدار أكبر حجماً وأعلى مخاطرةً وأكثر عرضةً للانكسار. كان الخوف يتراكم ليُنتج تحديداً النتيجة التي يخشاها الجميع.
كيف تعاملنا مع الأمر
وضعنا عدداً من المبادئ قبل أن نكتب سطراً واحداً من كود الاختبار:
- ابدأ من الأعطال، لا من الأدوات. دع أعطال الأشهر الستة الماضية تدلّنا على المواضع التي كانت الجودة تتسرّب منها فعلاً، بدلاً من التخمين.
- احمِ المسارات الحرجة أولاً. ملاحقة نسبة تغطية معيّنة فخّ؛ ما أردناه هو تلك المسارات القليلة التي يكلّف انكسارها مالاً حقيقياً أو ثقةً حقيقية.
- اجعل خط الـ pipeline قادراً على الرفض. مجموعة اختبارات لا تستطيع إيقاف دمجٍ خاطئ هي توثيق، لا شبكة أمان.
- قدِّم الجودة إلى الأمام. التحقق مسؤولية من يكتب الكود، بدعمٍ من شخص وظيفته تصميم كيفية فحص هذا الكود.
- صغّر وحدة التغيير. الإصدارات الأصغر والأكثر تواتراً أسهل في الفهم وأرخص بكثير في الإصلاح.
ما الذي فعلناه فعلاً
قضينا الأسبوعين الأولين في القراءة لا الكتابة — نراجع كل hotfix وكل عطلٍ من نصف العام السابق. ظهر نمطٌ واضح على الفور تقريباً: الغالبية العظمى من أعطال الإنتاج كانت متركّزة في مسارات قليلة — المصادقة (authentication)، والفوترة، ومسارات الإنشاء والقراءة والتحديث الأساسية في قلب المنتج. دلّنا ذلك بدقة على مواضع الإنفاق، ومواضع الامتناع عنه.
بعدها بنينا طبقةً رفيعة عن قصد من اختبارات الـ regression الآلية حول تلك المسارات الحرجة: اختبارات end-to-end للرحلات التي يلاحظها العميل فعلاً، واختبارات integration للوصلات الكامنة تحتها. وربطنا المجموعة بالـ CI بحيث يُوقِف البناء الأحمر أي عملية دمج — بلا استثناءات ولا تجاوزات. وأدخلنا الـ feature flags حتى يصبح نشر الكود وإطلاق الميزة قرارَين منفصلين: يمكن للعمل الجديد أن يُنشَر مطفأً ثم يُشغَّل حين يصبح جاهزاً بحق.
إلى جانب الأتمتة، أدخلنا قائمة تحقّق خفيفة لكل إصدار، ودرّبنا أحد المهندسين ليتولّى دور QA مخصّص — لا بوصفه من يمسك الأخطاء في النهاية، بل بوصفه من يصمّم كيفية التحقق من كل تغيير منذ البداية. ومنحت اختبارات الـ smoke التي تعمل على الـ staging ثم بعد كل نشرٍ للإنتاج الفريقَ إشارةً سريعة وصادقة بأن الجوهر ما زال يعمل.
النتيجة
| المقياس | قبل | بعد |
|---|---|---|
| الأخطاء الحرجة التي تصل إلى الإنتاج في كل إصدار | عدّة أخطاء في كل مرة | واحد تقريباً، وغالباً لا شيء |
| زمن اختبار الـ regression | نحو أسبوع، يدوي بالكامل | أقل من يوم، آلي في معظمه |
| التغطية الآلية للمسارات الحرجة | شبه معدومة | غالبية المسارات الحرجة |
| إصلاحات الطوارئ (hotfixes) | عدّة مرات شهرياً | نادرة |
| وتيرة الإصدار | كل بضعة أسابيع، بتوتّر | أسبوعياً، كروتينٍ معتاد |
الرقم الأهم بالنسبة للعميل لم يكن أي بندٍ منفرد في هذا الجدول، بل أن الأخطاء المتسرّبة انخفضت بنحو ثلاثة أضعاف بينما ازدادت الإصدارات تواتراً لا تباعداً. الثقة، ما إن وُجِدت، غيّرت السلوك من تلقاء نفسها. فحين وثق الفريق بأن الـ pipeline سيمسك الأخطاء الواضحة، توقّف عن اكتناز التغييرات، وصار انكسار شيءٍ ما — في المرّات النادرة التي يحدث فيها ذلك — أمراً يستغرق إيجاده والتراجع عنه دقائق، لا أمسيةً محمومة.
ما الذي صنع الفارق
ثلاثة دروس تنتقل إلى أي فريق تقريباً في هذا الموقف:
- التغطية قرار فرز، لا نسبة مئوية. الأعطال السابقة هي التي دلّتنا على المسارات الجديرة بالحماية. أما الاختبارات المكتوبة لرفع رقمٍ ما فهي جهدٌ يُنفَق حيث لم يكن الفشل ليؤذي أصلاً.
- الاختبار لا قيمة له ما لم يستطع الـ pipeline أن يقول لا. في اللحظة التي توقّف فيها البناء الأحمر عن كونه توصيةً وبدأ يمنع الدمج، صارت الجودة خاصيةً في النظام لا مسألة من تذكّر أن يفحص.
- ضمان الجودة نشاط تصميمي، لا بوابة أخيرة. نقل التحقق إلى المقدّمة — تحديد كيف سيُثبَت التغيير قبل كتابته — أنجز ما لا يستطيع أي قدرٍ من الفحص في نهاية الخط أن ينجزه.
ما زال الفريق يُطلق كل أسبوع، لكن التقويم صار يُقرأ بشكل مختلف: يوم الإصدار اليوم من أهدأ الأيام، لا اليوم الذي يتحفّز له الجميع. وهذه هي صيغة "الإنجاز" التي يستحق العمل من أجلها.