ما الذي يخفض نسبة اختبار أتمتة UI
المحدِّدات
إعادة تصميم لا تغيّر شيئًا في الوظائف تحوّل المجموعة إلى اللون الأحمر.
هنا يذهب معظم وقت الصيانة فعليًا.
الانتظار
التأخيرات الثابتة بطيئة وغير مستقرة رغم ذلك. والانتظار الصحيح يحتاج إلى معرفة ما الذي ينتظره.
معظم حالات عدم الاستقرار مصدرها هنا.
التغطية المكتوبة
أنت تغطي ما كتبه أحدهم، أي المسارات المثيرة للاهتمام لا المسارات التي تتعطل.
المحدِّدات والانتظار يُنتجان إخفاقات ليست أخطاءً برمجية. وكل إخفاق منها يستهلك جزءًا من استعداد الفريق للنظر في عملية البناء الحمراء التالية.
اللحظة التي تموت فيها مجموعة الاختبارات
يمكن عادةً تحديدها بأثر رجعي: الأسبوع الذي قال فيه أحدهم «أعد تشغيله فحسب» وكان محقًّا. بعد ذلك تصبح إعادة التشغيل أول رد على أي إخفاق، ويُعاد تشغيل أي انحدار فعلي حتى ينجح بالصدفة أو يُعزَل.
لا أحد يقرر التوقف عن الثقة بالمجموعة. الثقة تتآكل.
حماية النسبة
أصلِح الاختبارات غير المستقرة قبل إضافة اختبارات جديدة. قرار غير محبوب لكنه صحيح. الاختبار الجديد المضاف إلى مجموعة يتجاهلها الناس بلا قيمة.
اعزل الاختبارات علنًا لا بصمت. الاختبار المتخطَّى يجب أن يكون ظاهرًا وأن يكون له مالك، وإلا صارت قائمة التخطي المكان الذي تذهب إليه الاختبارات لتموت.
تعامَل مع إعادة التشغيل على أنها ملاحظة. إذا احتاج اختبار إلى إعادة تشغيل، فهناك خلل في الاختبار أو في البيئة. سجِّل ذلك بدل المضي قدمًا.
الجزء البنيوي
الانضباط يعالج المحدِّدات وحالات الانتظار، لكنه لا يعالج التكلفة الثالثة: التغطية محدودة بمقدار ما يستطيع شخص كتابته، والمنتج ينمو أسرع من ذلك، خصوصًا حين يأتي جزء كبير من الشيفرة من وكيل برمجي.
الخطوات المعبَّر عنها كنوايا بدل مسارات داخل DOM تُلغي نهائيًا حصة كبيرة من إخفاقات المحدِّدات، وهي أكبر عامل منفرد يؤثر في النسبة.
الطرفية
npm install -g @testsprite/testsprite-cli
testsprite setup
الإعداد نفسه متاح في لوحة تحكم TestSprite إن كنت تفضّل ألا تثبّت شيئًا محليًا. أما بقية واجهة CLI فتجدها في مستودع CLI.
استعادة نسبة متدهورة
إذا وصلت المجموعة إلى النقطة التي يعيد عندها الناس التشغيل بدل التحقيق، فإن الانضباط من الآن فصاعدًا لا يحل المشكلة، لأن الضجيج القائم يواصل ترسيخ العادة. الاستعادة تتطلب إعادة ضبط متعمَّدة.
خذ آخر خمسين إخفاقًا وصنّف كل واحد منها: حقيقي أم محدِّد أم توقيت أم بيئة. تلك الساعة تكشف لك أيّ التكاليف الثلاث تعاني منه فعلًا، وهو عادةً متركّز لا موزّع. عالج تلك الفئة الواحدة في المجموعة كلها بدل إصلاح الاختبارات كلما أخفقت.
ثم اعزل كل ما لا يزال يخفق، مع مالك وتاريخ، ودع ما تبقى من المجموعة يكون أخضر. مجموعة صغيرة خضراء يثق بها الناس أثمن من مجموعة كبيرة حمراء تعلّموا تجاهلها، وهي الحالة الوحيدة التي يمكن أن تتحسن النسبة انطلاقًا منها.
شغّلها حيث تكون تكلفة الإخفاق أقل
مع كل طلب سحب، بحيث يشير الإخفاق إلى تغيير واحد لا إلى أسبوع كامل من التغييرات.
GitHub App هو webhook تُعدّه في لوحة تحكم TestSprite. يستمع إلى حدث النشر الذي يصدره مسار التسليم لديك أصلًا، فلا يتغير شيء في مستودعك.
GitHub Actions يضع الخطوة داخل سير العمل الخاص بك، ويجري إعداده من الطرفية.
كيف يحمي TestSprite هذه النسبة
بشكل مباشر، عبر إزالة أكبر مصدر للإخفاقات الكاذبة. فالخطوات نوايا لا محدِّدات مواقع، ولذلك لا تنتج عن التغييرات الشكلية التي تسبب معظم أعطال المحدِّدات عمليات بناء حمراء. والانتظار يُعالَج بدل أن يكون تمرين ضبط لكل اختبار على حدة، وهو ما يزيل معظم ما تبقى.
تُولَّد التغطية انطلاقًا من منتجك وتُنقَّح بلغة طبيعية، ولذلك فإن توسيع المجموعة لا يعني زيادة الصيانة بالقدر نفسه، وهي الزيادة التي تفرض عادةً المفاضلة بين التغطية والثقة.
والنتيجة مجموعة اختبارات يكون الإخفاق فيها مفاجئًا. تلك هي الحالة التي يحقق فيها الناس بدل أن يعيدوا التشغيل، وهي الحالة الوحيدة التي يمكن أن تستمر التغطية في النمو انطلاقًا منها دون أن يتحول الأمر كله بصمت إلى مجرد ديكور.
ما معدل النجاح الذي ينبغي أن نتوقعه؟
مرتفع بما يكفي ليكون البناء الأحمر مفاجأة. فإذا صارت الإخفاقات روتينية، فإن المجموعة تُبلّغ عن نفسها لا عن المنتج.
كيف نصلح الاختبارات غير المستقرة؟
حدّد إن كانت المشكلة في محدِّد أو في انتظار. المحدِّدات تحتاج إلى مرتكزات ثابتة، والانتظار يجب أن ينتظر حالةً بعينها. وهناك فئة ثالثة هي بيئة غير مستقرة فعلًا، ولا يصلحها أي تغيير في الاختبارات.
هل يستحق الأمر حذف الاختبارات القديمة؟
نعم. الاختبار الذي لا يثق به أحد ولا يصونه أحد تكلفة بلا فائدة. وحذفه أفضل من تخطّيه.
هل ينبغي أن تمنع المجموعة عمليات الدمج؟
نعم، متى صارت النسبة سليمة. أما قبل ذلك، فمنع الدمج استنادًا إلى مجموعة غير جديرة بالثقة يعلّم الناس الالتفاف عليها.
كيف نقيس ذلك؟
تتبّع كم إخفاقًا يتبيّن أنه حقيقي. وإذا لم يكن أحد يعرف الرقم، فهذه بحد ذاتها هي الملاحظة.
التغطية ليست الرقم المهم.
اختبار أتمتة UI يحيا أو يموت بنسبة عمليات البناء الحمراء التي تعود إلى أخطاء حقيقية. أصلِح الاختبارات غير المستقرة قبل إضافة اختبارات جديدة، وتعامَل مع إعادة التشغيل على أنها ملاحظة، واستخدم خطوات قائمة على النوايا لإزالة إخفاقات المحدِّدات التي تتآكل معها الثقة.