بناء إطار عمل لأتمتة الاختبارات: الأجزاء التي لا يضع لها أحد ميزانية

ما الذي يحتويه إطار عمل أتمتة الاختبارات فعلياً

أضف إلى ذلك تقارير يقرأها الناس فعلاً، وإعدادات البيئات، وسياسة إعادة المحاولة، وطريقة لعزل اختبار غير مستقر دون فقدانه. أما الاختبارات نفسها فهي عادةً الجزء الأصغر.

التكلفة الخفية

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

متى يكون البناء هو القرار الصحيح

• متطلبات غير اعتيادية. بروتوكول أو منصة أو قيد امتثال لا يتعامل معه أي حل جاهز.

• الاختبار جوهر المنتج. إذا كنت تبيع الموثوقية، فقد يكون امتلاك منظومة تشغيل الاختبارات قراراً استراتيجياً.

• لديك طاقة مستدامة. ليس شخصاً لربع سنة. بل مالكاً مسؤولاً لسنوات.

ومتى لا يكون كذلك

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

علامات تدل على أن الإطار قد صار هو المنتج

من المفيد امتلاك بضع علامات ملموسة، لأن هذا التحول يحدث تدريجياً ولا يعلن عنه أحد.

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

أي اثنتين من هذه العلامات تعنيان أن لديك منتجاً قاعدة عملائه الداخلية فريق واحد. وهذا ليس خطأً بالضرورة؛ فكثير من المؤسسات اتخذت هذا الخيار عن قصد. المشكلة تنشأ فقط حين يحدث ذلك دون أن يختاره أحد، وهي الحالة المعتادة.

الطريق الوسط

احتفظ بالاختبارات المكتوبة يدوياً للحالات التي حددتها عن قصد، ودع التغطية المولّدة تتكفل بالاتساع، مع حلّ مشكلات الجلسات والبيانات والترتيب والتنظيف كجزء من المنتج بدلاً من أن تكون جزءاً من بنيتك التحتية.

الإعداد نفسه متاح في لوحة تحكم TestSprite إن كنت تفضّل عدم تثبيت أي شيء محلياً. أما بقية واجهة CLI فتجدها في مستودع CLI.

إذا كان خط الإنتاج تابعاً لفريق آخر، فإن GitHub App هو أقل الطرق مقاومة: فهو webhook، ولا يغيّر شيئاً في مستودعك، ويُستدعى حين تُبلّغ عملية البناء لديك بأن الإصدار الجديد صار منشوراً. وإذا كنت تريد بدلاً من ذلك أن يظهر الفحص داخل المستودع، فيمكن لخطوة في GitHub Actions أن تقوم بذلك.

ما الذي تحصل عليه بدلاً من بنائه

الأجزاء التي كانت ستصبح بنيتك التحتية تأتيك ضمن المنتج. فـ Auto-Authentication يُبقي الجلسات حيّة طوال التشغيل، و Dynamic Variables تنقل القيم بين الاستدعاءات، و Dependency Chains تستنتج ترتيب التنفيذ، و Auto-Cleanup يحذف بالضبط ما أنشأه التشغيل. وتأتي معها التقارير وإعدادات البيئات وسلوك إعادة المحاولة، فلا يتحول أي منها إلى ملف لا يريد أحد لمسه.

تُولَّد التغطية من منتجك وتُنقَّح بلغة عادية، وهو ما يزيل النصف الآخر من التكلفة: الجزء الذي يتطلب أن يكتب كل اختبارٍ شخصٌ وقته متنازَع عليه.

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