أصبحت أدوات أتمتة الاختبار جزءًا قياسيًا من سير عمل DevOps. تمتلكها معظم الفرق الهندسية. وترتبط معظم الفرق الهندسية أيضًا بعلاقة معقدة معهم – حيث يستغرق تشغيلها وقتًا طويلاً للغاية، والاختبارات التي تفشل دون سبب واضح، والشك الهادئ في أن خط الأنابيب الأخضر لا يعني في الواقع أن كل شيء على ما يرام.
نادرا ما تكون المشاكل ناجمة عن أدوات سيئة. ويرجع السبب في ذلك إلى الطريقة التي يتم بها اعتماد الأدوات وتكوينها وصيانتها. تظهر نفس الأخطاء عبر فرق ذات أحجام مختلفة ومجموعات مختلفة ومستويات مختلفة من نضج DevOps. إن فهمها هو أسرع طريقة للحصول على قيمة أكبر من الأدوات المتوفرة لديك بالفعل.
اقرأ أيضًا: DevOps الأكثر ذكاءً مع Kite: AI يلتقي Kubernetes
يحدث الخطأ الأكثر شيوعًا قبل كتابة سطر واحد من كود الاختبار. يقرر الفريق أنهم بحاجة إلى أتمتة أفضل للاختبار، ويبحثون عن الخيارات المتاحة، ويختارون شيئًا شائعًا، ثم يحاولون جعله مناسبًا لوضعهم الفعلي.
ينتج عن هذا التسلسل أدوات تحل المشكلات النظرية بدلاً من المشكلات الحقيقية. يحتاج الفريق الذي يعاني من مشكلة معدل فشل التغيير إلى تغطية اختبارية تكتشف الانحدارات السلوكية قبل النشر. يحتاج الفريق الذي يعاني من مشكلة بطء خط الأنابيب إلى تنفيذ اختبار أسرع واختيار اختبار أكثر ذكاءً. يحتاج الفريق الذي يعاني من اختبارات غير مستقرة إلى عزل أفضل للبيئة. هذه مشكلات مختلفة وتشير إلى قرارات مختلفة للأدوات.
قبل تقييم أي أداة لأتمتة الاختبار، السؤال الأكثر فائدة هو: ما هو وضع الفشل المحدد الذي تهدف هذه الأداة إلى معالجته؟ ما هي حوادث الإنتاج التي حدثت في الأشهر الستة الماضية والتي كان من الممكن أن يتم اكتشافها بشكل أفضل من خلال أتمتة الاختبار؟ البدء من هذا السؤال ينتج عنه متطلبات أكثر وضوحًا للأداة وخيارات أفضل للأداة.
قبل تقييم أدوات محددة، يجب فهم النطاق الحالي أدوات أتمتة الاختبار يبدو عبر طبقات اختبار مختلفة نقطة بداية مفيدة.
التعامل مع طبقة التكامل باعتبارها فكرة لاحقة
تتمتع معظم فرق DevOps بتغطية معقولة لاختبار الوحدة وشكل من أشكال الاختبار الشامل. طبقة التكامل – حيث تتفاعل الخدمات مع بعضها البعض من خلال واجهات برمجة التطبيقات والتبعيات المشتركة – هي المكان الذي ينقص فيه الاستثمار في أتمتة الاختبار باستمرار.
هذا هو المكان الذي تنشأ فيه معظم حالات فشل الإنتاج فعليًا. ليس في منطق الوظيفة المعزولة الذي تغطيه اختبارات الوحدة. ليس في رحلات المستخدم الكاملة التي تتحقق منها الاختبارات الشاملة. في الحدود بين الخدمات، حيث يصبح مخرج أحد المكونات مدخلاً لمكون آخر، يحتاج كلا الجانبين إلى الاتفاق على الشكل الذي يبدو عليه هذا التبادل.
أدوات التشغيل الآلي للاختبار التي تركز بشكل حصري على طبقة واحدة تترك هذه الفجوة دون معالجة. يمكن لمجموعة اختبار الوحدة الشاملة ومجموعة من السيناريوهات الشاملة المرور بينما تنكسر حدود الخدمة بهدوء في ظل ظروف لم يتم تصميم أي من الطبقتين لاختبارها.
تتطلب معالجة طبقة التكامل على وجه التحديد أدوات يمكنها التحقق من صحة سلوك واجهة برمجة التطبيقات (API) عبر حدود الخدمة، والتعامل مع سلوك التبعية بشكل منهجي، وتشغيلها بسرعة كافية لتناسب دورة مراجعة طلب السحب. تقوم الفرق التي تتخطى هذه الطبقة باختبار أجزاء النظام التي نادرًا ما تفشل وتترك الأجزاء التي تفشل في أغلب الأحيان مكشوفة.
اقرأ أيضًا: لماذا تعد بنية API-First العمود الفقري للمنصات الرقمية الحديثة
التقليل من عبء الصيانة
تنشئ أدوات أتمتة الاختبار التزامات صيانة مستمرة يسهل الاستهانة بها أثناء التقييم الأولي. يبدو الإعداد واضحًا. الجناح الأول يعمل بشكل نظيف. وبعد ستة أشهر، كبرت المجموعة، وتطورت قاعدة التعليمات البرمجية، ويقضي شخص ما يومين في كل سباق للحفاظ على عمل الاختبارات بدلاً من كتابة اختبارات جديدة.
يتركز عبء الصيانة في مجالين. أولاً، يجب أن تظل النماذج والنماذج التي تمثل تبعيات خارجية محدثة مع تغير تلك التبعيات. إن النموذج الوهمي الذي تم كتابته ضد خدمة تم تحديثها ثلاث مرات لم يعد بمثابة اختبار للسلوك الحقيقي – بل هو اختبار لطريقة تصرف الخدمة عند كتابة النموذج الوهمي. ثانيًا، تنتج بيئات الاختبار التي تتشارك الحالة بين عمليات التشغيل حالات فشل غير حتمية تستغرق وقتًا طويلاً في التشخيص والإصلاح.
الأدوات التي لديها نهج منظم للحفاظ على تمثيلات التبعية الحالية تقلل من المشكلة الأولى. الأدوات التي تفرض عزل الاختبار وتدعم البيئات القابلة للتكرار تقلل من الثانية. هذه ليست ميزات مثيرة للتقييم في العرض التوضيحي، ولكنها تحدد ما إذا كانت مجموعة الاختبار لا تزال موثوقة ويتم صيانتها بعد عام من اعتمادها.
تحسين نسبة التغطية بدلاً من جودة الإشارة
نسبة التغطية هي المقياس الذي تتبعه معظم الفرق لأتمتة الاختبار. إنها أيضًا إحدى الإشارات الأقل فائدة لمعرفة ما إذا كانت الأتمتة تعمل بالفعل أم لا.
يمكن للمجموعة تنفيذ 90 بالمائة من أسطر التعليمات البرمجية مع تفويت حالات فشل التكامل وحالات الحافة وأنماط الاستخدام الواقعية التي تسبب معظم حوادث الإنتاج. إن التغطية العالية المبنية على الاختبارات التي تتحقق من صحة ما افترض المطورون أن النظام سيفعله، وليس ما يفعله بالفعل، توفر الثقة التي لم يتم اكتسابها.
بدلاً من ذلك، فإن المقياس الذي يستحق التتبع هو عدد المرات التي تكتشف فيها مجموعة الاختبار الانحدارات الحقيقية قبل أن تصل إلى الإنتاج. من الصعب قياس هذا الرقم، لكنه يعكس ما يفترض أن تفعله أتمتة الاختبار في الواقع. تقوم الفرق التي تحول تركيزها من نسبة التغطية إلى معدل التقاط الانحدار باتخاذ قرارات مختلفة بشأن الأدوات، وكتابة اختبارات مختلفة، وبناء مجموعات تظل ذات معنى مع تطور النظام.
اتخاذ قرارات الأداة في عزلة
لا تعمل أدوات أتمتة الاختبار بشكل منفصل. وهي تتصل بخطوط أنابيب CI/CD وأنظمة النشر ومنصات إمكانية المراقبة وسير عمل التحكم في الإصدار الذي يستخدمه المطورون كل يوم. إن الأداة التي تعمل بشكل جيد من تلقاء نفسها ولكنها تخلق احتكاكًا في خط الأنابيب سيتم حلها في النهاية.
يعد سطح التكامل لأداة أتمتة الاختبار أحد أهم معايير التقييم وواحدًا من أكثر المعايير التي تعاني من نقص الوزن باستمرار. سيتم استخدام أداة ذات دعم أصلي لمنصة CI/CD التي يستخدمها الفريق، ومخرجات الفشل الواضحة التي تظهر في نفس لوحات المعلومات التي يراقبها المطورون بالفعل، ونموذج التكوين الذي يناسب البنية التحتية الحالية بشكل صحيح. إن الأداة التي تتطلب برمجة نصية مخصصة للاتصال بخط الأنابيب، أو تنتج مخرجات فاشلة بتنسيق لا يقرأه أي شيء آخر، أو تحتاج إلى بيئة منفصلة للتشغيل، ستؤدي إلى إنشاء نوع من النفقات العامة التي تؤدي في النهاية إلى تجاوز الفرق لها تحت ضغط الموعد النهائي.
تؤدي قرارات اعتماد الأداة التي يتم اتخاذها باستخدام سطح التكامل كمعيار أساسي إلى إنتاج إعدادات أتمتة تدوم أكثر من الحماس الأولي وتبقى جزءًا من سير العمل بدلاً من أن تصبح دينًا تقنيًا.
اقرأ أيضًا: أفضل أدوات DevOps للتكامل السلس لـ Salesforce CI/CD
بناء الجناح مرة واحدة وتركه
مجموعات أتمتة الاختبار التي تم إنشاؤها مرة واحدة ولم يتم صيانتها بشكل فعال تتدهور بشكل يمكن التنبؤ به. تتم إضافة ميزات جديدة دون تغطية الاختبار المقابلة. تؤدي الواجهات المتغيرة إلى كسر الاختبارات الحالية التي لا يقوم أحد بتحديثها على الفور. تتراكم الاختبارات غير المستقرة حتى يبدأ المطورون في إعادة تشغيل حالات الفشل بدلاً من التحقيق فيها.
تتعامل الفرق التي تحصل على قيمة مستدامة من أتمتة الاختبار مع المجموعة كجزء حي من قاعدة التعليمات البرمجية بدلاً من مشروع له تاريخ اكتمال. تعد تغطية الاختبار للميزات الجديدة جزءًا من تعريف “تم”. تأتي تغييرات الواجهة مع تحديثات اختبارية في نفس طلب السحب. يتم عزل الاختبارات غير المستقرة وإصلاحها بنفس أولوية أخطاء الإنتاج.
لتلخيص
هذه ليست مشكلة أداة – إنها مشكلة ممارسة. لكن الأدوات الصحيحة تجعل استمرار هذه الممارسات أسهل. الأدوات ذات مخرجات الفشل الواضحة تجعل التحقيق في الاختبار غير المستقر أسرع. الأدوات التي تولد اختبارات من سلوك النظام الحقيقي بدلاً من التأليف اليدوي تقلل من الحمل الزائد للحفاظ على التغطية محدثة. يحدد اختيار الأداة ما إذا كان من السهل أو الصعب الحفاظ على ممارسات الاختبار الجيدة بمرور الوقت.
