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

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

 

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

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

 

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

 

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

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

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

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

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

 

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

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

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

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

 

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

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

 

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

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

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

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

تبادل الأفكار القيمة.

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

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

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

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

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

 

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

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

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

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

 

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

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

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

 

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

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

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

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

 

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 والمزيد

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

 

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

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