ما هو اختبار التحول إلى اليسار؟ وماذا يعني ذلك بالنسبة ل DevOps؟

منهجية اختبار التحول إلى اليسار هي نهج لاختبار البرامج يجلب متطلبات الاختبار في وقت مبكر من دورة تطوير البرامج.

 

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

نموذج الشلال بواسطة بول هودلي. تستخدم بموجب رخصة المشاع الإبداعي.

 

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

 

اختبار التحول إلى اليسار – وضع الأساس

لحسن الحظ ، ساعدت الدروس المكلفة المستفادة من أخطاء التطوير السابقة في الدخول في طريقة التحول إلى اليسار. أدركت المنظمات أن تحديد المشكلات في وقت متأخر من اللعبة لم يكن مكلفا للغاية فحسب ، بل كان محفوفا بالمخاطر أيضا. ذكرت مقالة TechRepublic من مايو 2019 أن متوسط التكلفة السنوية لإصلاح الأخطاء المرئية في البرامج يزيد عن 400,000 دولار. ليس بالضبط تغيير غب.

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

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

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

 

صعود اختبار التحول إلى اليسار و Agile و DevOps

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

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

وهذا عامل مهم آخر حول اختبار التحول إلى اليسار. في اختبار الشلال التقليدي ، تقع مسؤولية اختبار وإدارة جودة المنتج على عاتق فريق ضمان الجودة. في اختبار التحول الأيسر وبيئات Agile ، يقوم المطورون والمختبرون بإجراء الاختبار الفعلي ، لكن المسؤولية تقع في النهاية على عاتق الجميع بسبب نهجها التعاوني متعدد الوظائف أثناء التطوير. اليوم ، هناك أربعة طرق مختلفة لتحويل الاختبار إلى اليسار: الاختبار التقليدي ، والتزايدي ، والرشيق / DevOps ، واختبار التحول الأيسر المستند إلى النموذج.

 

أنواع اختبار التحول إلى اليسار

في السنوات الأخيرة ، أصبح مصطلح DevOps أكثر من كلمة طنانة للتسويق ومنتجات البرمجيات وحتى الأوصاف الوظيفية. ببساطة ، DevOps هو إطار عمل بديل ضمن نهج Agile الذي يهدف إلى الجمع بين فرق التطوير والعمليات. تاريخيا ، كان لكل قسم أهدافه المحترمة ، والمتناقضة في بعض الأحيان. يقوم المطورون بالإبداع والتصميم والابتكار. تركز فرق العمليات على البنية التحتية و “إبقاء الأضواء مضاءة” مع المراقبة المستمرة لضمان التوافر. وبالمثل ، تم إنشاء DevOps خصيصا لتحقيق المزيد من التعاون والتعليقات وخفة الحركة بين هذه الإدارات. يشار إلى DevOps أيضا عند الحديث عن CI / CD ( التكامل المستمر والنشر المستمر) والأتمتة ، ولكن حقيقة أن المؤسسة تستخدم CI / CD والأتمتة ، لا تجعلها معتمدة تلقائيا من DevOps.

 

تحميل أفضل ممارسات الاختبار لبيئات DevOps

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

اختبار الحمل المستمر.

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

شارك رؤى قيمة.

أشرك فريق DevOps الخاص بك في أنشطة تحليل النتائج. لا تمارس إخفاء المعلومات. شارك جميع اختبارات الحمل (بما في ذلك اختبار حمل السيلينيوم) ومراقبة النتائج مع مهندسيك لتحديد سبب جميع المشكلات.

مراقبة جميع الطبقات.

يعني التحول إلى اليسار أيضا وجود مراقبة شبيهة بالإنتاج في مراحل التطوير وضمان الجودة. لن يكون لديك الوقت لإعادة إنتاج الأخطاء باستمرار في خطوط أنابيب التطوير الرشيقة. تأكد من جمع مقاييس استخدام الواجهة الأمامية والخلفية والبنية التحتية 24/7 للمراحل غير الإنتاجية.

خط الأساس والمعيار.

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

 

دمج اختبار الأداء في منهجية التحول إلى اليسار

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

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

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

 

منصة LoadView: اختبار الحمل المستند إلى السحابة في المتصفحات الحقيقية

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

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

 

البرمجة النصية أصبحت سهلة: مسجل الويب EveryStep

يستخدم LoadView مسجل برنامج نصي سهل الاستخدام يسمى مسجل الويب EveryStep. يمكن للمستخدمين بسهولة إنشاء إجراءات برمجة نصية متقدمة تحاكي إجراءات المستخدم الحقيقية باستخدام واجهات برمجة التطبيقات وتطبيقات الويب ومواقع الويب. للتحقق من صحة أوقات الاستجابة الشاملة للتطبيقات من جانب العميل ، يمكن للمستخدمين ببساطة التنقل عبر حالة الاختبار الخاصة بهم وتسجيل كل إجراء. يمكن أن يساعد فهم مقدار الحمل الذي يمكن أن تتعامل معه واجهة برمجة التطبيقات أو تطبيق الويب أثناء مرحلة التطوير المبكرة المطورين في هذه المجالات الهامة:

• تحديد خطوط الأساس لوقت الاستجابة تحت أرقام تحميل المستخدم المحددة
• تحديد اختناقات الأداء
• العثور على الحدود العليا لأنظمتك الحالية لتخطيط السعة
• تحليل أداء الخادم (وحدة المعالجة المركزية والذاكرة وعرض النطاق الترددي وإدخال / إخراج القرص) وأوقات استجابة قاعدة البيانات

يدعم المسجل أيضا أكثر من 40 متصفحا وأجهزة سطح المكتب / الجوال الشائعة ، بالإضافة إلى تقنيات الويب ولغات البرمجة ، مثل AJAX و HTML5 و JavaScript و Flash و Silverlight والمزيد. يستخدم LoadView هذه البرامج النصية لتنفيذ اختبارات الإجهاد والتحميل عند الطلب ، من 13+ موقعا عالميا (الولايات المتحدة وكندا وأمريكا الجنوبية وأوروبا وآسيا والمحيط الهادئ) ، مما يمنح مهندسي الاختبار بيانات أداء في العالم الحقيقي من المتصفحات الفعلية. تذكر أن تنفيذ اختبار داخلي يمكن أن يخبرك بمدى جودة تعامل تطبيقك أو موقعك مع زيادة حركة المرور من داخل شبكتك الخاصة ، ولكنه لن يعكس أبدا ظروف العالم الحقيقي. يمكن أن تؤثر التطبيقات والمواقع التي لم يتم اختبارها وتحسينها بشكل صحيح سلبا على الإحالات الناجحة ، وفي النهاية على الأرباح.

 

LoadView: المرونة في اختبار سيناريوهات العالم الحقيقي

يمنح LoadView المستخدمين خيار توزيع تحميل المستخدم بين المواقع الجغرافية استنادا إلى النسبة المئوية لحركة المرور إلى موقعك. على سبيل المثال ، إذا كنت تعلم أن نسبة معينة من عملائك ومستخدميك يأتون من موقع جغرافي معين ، فيمكنك تحديد تلك المناطق المحددة لاختبارها. تستخدم المنصة Amazon Web Services (AWS) و Azure Cloud Services لإنشاء مستخدمين افتراضيين. علاوة على ذلك ، يمكن للمستخدمين اتخاذ اختبار الحمل خطوة أخرى إلى الأمام من خلال تخصيص نوع منحنى الحمل. يوفر هذا مرونة أكبر لمهندسي الاختبار ، اعتمادا على السيناريو الفريد الخاص بهم. يمكن لمستخدمي LoadView الاختيار من بين ثلاثة منحنيات تحميل مختلفة:

منحنى خطوة التحميل

• • يبدأ بعدد محدد مسبقا من المستخدمين المتزامنين ويزيد الحمل تدريجيا لمعرفة كيف يمكن لموقع الويب الخاص بك التعامل مع ارتفاع في حركة المرور ومقارنته بحركة المرور المتوقعة.

منحنى قائم على الهدف

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

منحنى ديناميكي قابل للتعديل

• • يسمح هذا الاختبار للمستخدمين بضبط الحمل أثناء تشغيل الاختبار للكشف عن حدود أداء مواقع الويب أو سعة الخادم.

بعد انتهاء الاختبارات ، يقوم LoadView تلقائيا بإنشاء تقارير تساعد الفرق في قياس نجاح مؤشرات الأداء الرئيسية (مؤشرات الأداء الرئيسية) ، مثل عدد المستخدمين المتزامنين والأخطاء ومتوسط أوقات الاستجابة واستخدام وحدة المعالجة المركزية والإنتاجية وزمن الوصول والمزيد. تعد هذه المقاييس ضرورية للمطورين وفرق DevOps وضمان الجودة لأنها تساعد في الكشف عن الاختناقات في العالم الحقيقي التي يمكن أن تؤثر على أداء المستخدم النهائي.

 

بعد التحول إلى اليسار ، لا تنس التحول إلى اليمين

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

مراقبة خدمات الويب

• • وقت التشغيل وأداء خدمات الويب ، مثل HTTP / S و SOAP / REST والمزيد

مراقبة صفحة الويب

• • أداء صفحة الويب في المتصفحات الحقيقية ، وتحديد أبطأ وأسرع العناصر بمرور الوقت

مراقبة تطبيقات الويب

• • مراقبة تطبيقات الويب المعقدة ، مثل AJAX و PHP و Ruby و Flash والمزيد

مراقبة البنية التحتية

• • وظائف وأداء خوادم وبروتوكولات الإنترنت ، مثل HTTP / S والبريد الإلكتروني والوسائط المتدفقة و VoIP والمزيد

تسمح هذه الأنظمة الأساسية للمستخدمين بإعداد مراقبة مستمرة بناء على عتبات مخصصة ويمكنها تنبيه أفراد أو فرق محددة عند حدوث أخطاء حتى يتمكنوا من العمل على إصلاح المشكلات قبل التأثير المحتمل على العديد من المستخدمين.

 

اختبار التحول إلى اليسار: جيد للأعمال وراحة البال

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