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

الاختبار المستمر هو عملية تنفيذ اختبارات مؤتمتة كجزء من مسار تسليم البرمجيات للحصول على تغذية راجعة فورية حول المخاطر التجارية المرتبطة بإصدار مرشح للبرمجيات. ^{[ 1 ] [ 2 ]} وقد طُرح الاختبار المستمر في الأصل كوسيلة لتقليل وقت انتظار التغذية الراجعة للمطورين من خلال إدخال اختبارات يتم تشغيلها بواسطة بيئة التطوير، بالإضافة إلى الاختبارات التقليدية التي يتم تشغيلها بواسطة المطورين/المختبرين. ^{[ 3 ]}

بالنسبة للاختبار المستمر، يمتد نطاق الاختبار من التحقق من صحة المتطلبات أو قصص المستخدم من الأسفل إلى الأعلى إلى تقييم متطلبات النظام المرتبطة بأهداف العمل الشاملة. ^{[ 4 ]}

في العقد الثاني من الألفية الثانية، أصبح البرمجيات عاملًا أساسيًا في تمييز الشركات. ^{[ 5 ]} ونتيجةً لذلك، تتوقع المؤسسات الآن من فرق تطوير البرمجيات تقديم برمجيات أكثر ابتكارًا ضمن دورات تسليم أقصر. ^{[ 6 ] [ 7 ]} ولتلبية هذه المتطلبات، اتجهت الفرق إلى منهجيات مرنة ، مثل أجايل ، وديف أوبس ، والتسليم المستمر ، في محاولة لتسريع دورة حياة تطوير الأنظمة (SDLC). ^{[ 8 ]} بعد تسريع جوانب أخرى من مسار التسليم، تجد الفرق عادةً أن عملية الاختبار تعيقها عن تحقيق الفوائد المرجوة من مبادرة تسريع دورة حياة تطوير الأنظمة. ^{[ 9 ]} ولا يزال الاختبار وعملية الجودة الشاملة يمثلان تحديًا لعدة أسباب رئيسية. ^{[ 10 ]}

• أصبحت عمليات الاختبار التقليدية بطيئة للغاية. فقد تغيرت مدة التكرار من شهور إلى أسابيع أو أيام مع تزايد شعبية منهجيات Agile وDevOps والتسليم المستمر. ولم تعد أساليب الاختبار التقليدية، التي تعتمد بشكل كبير على الاختبار اليدوي واختبارات واجهة المستخدم الرسومية الآلية التي تتطلب تحديثات متكررة، قادرة على مواكبة هذا التطور. ^{[ 9 ] [ 11 ]} عند هذه النقطة، تميل المؤسسات إلى إدراك الحاجة إلى توسيع نطاق جهودها في مجال أتمتة الاختبار. ^{[ 1 ] [ 12 ]}
• حتى بعد إضافة المزيد من الأتمتة إلى عملية الاختبار الحالية، لا يزال المديرون يفتقرون إلى فهم كافٍ لمستوى المخاطر المرتبطة بالتطبيق في أي وقت. ^{[ 2 ]} يُعدّ فهم هذه المخاطر أمرًا بالغ الأهمية لاتخاذ قرارات سريعة بشأن الموافقة أو الرفض في عمليات التسليم المستمر. ^{[ 13 ]} إذا طُوّرت الاختبارات دون فهم ما تعتبره الشركة مستوى مقبولًا من المخاطر، فمن الممكن أن يكون لدينا إصدار تجريبي يجتاز جميع الاختبارات المتاحة، لكن قادة الأعمال لن يعتبروه جاهزًا للإصدار. ^{[ 14 ]} لكي تُشير نتائج الاختبار بدقة إلى ما إذا كان كل إصدار تجريبي يلبي توقعات العمل، يجب أن يستند نهج تصميم الاختبارات إلى مدى تقبّل الشركة للمخاطر المتعلقة بالأمان والأداء والموثوقية والامتثال. ^{[ 5 ]} بالإضافة إلى وجود اختبارات الوحدة التي تتحقق من التعليمات البرمجية على مستوى دقيق للغاية من الأسفل إلى الأعلى، هناك حاجة إلى مجموعة أوسع من الاختبارات لتوفير تقييم شامل لمخاطر العمل للإصدار التجريبي. ^{[ 4 ]}
• حتى مع أتمتة الاختبارات وفعاليتها في قياس مستوى المخاطر التجارية، فإن الفرق التي تفتقر إلى عملية جودة شاملة ومنسقة تواجه صعوبة في تلبية توقعات العمل ضمن دورات التسليم المضغوطة الحالية. ^{[ 4 ]} وقد ثبت أن محاولة إزالة المخاطر في نهاية كل دورة تطوير أبطأ بكثير وأكثر استهلاكًا للموارد من بناء الجودة في المنتج من خلال استراتيجيات منع العيوب، مثل اختبار التطوير . ^{[ 15 ] [ 16 ]}

تتبنى المؤسسات منهجية الاختبار المستمر لأنها تدرك أن هذه المشكلات تعيقها عن تقديم برمجيات عالية الجودة بالسرعة المطلوبة. كما أنها تدرك الأهمية المتزايدة للبرمجيات، فضلاً عن التكلفة المتزايدة لفشل البرمجيات، ولم تعد مستعدة للمفاضلة بين الوقت والنطاق والجودة. ^{[ 2 ] [ 17 ] [ 18 ]}

يهدف الاختبار المستمر إلى توفير تغذية راجعة سريعة ومستمرة بشأن مستوى المخاطر التجارية في أحدث إصدار تجريبي أو مرشح للإصدار. ^{[ 2 ]} ويمكن استخدام هذه المعلومات لتحديد ما إذا كان البرنامج جاهزًا للمضي قدمًا في مسار التسليم في أي وقت. ^{[ 1 ] [ 5 ] [ 13 ] [ 19 ]}

بما أن الاختبار يبدأ مبكرًا ويُنفذ باستمرار، فإن مخاطر التطبيق تُكشف فور ظهورها. ^{[ 6 ]} وبذلك، تستطيع فرق التطوير منع هذه المشكلات من الانتقال إلى المرحلة التالية من دورة حياة تطوير البرمجيات. وهذا يقلل الوقت والجهد اللازمين لاكتشاف العيوب وإصلاحها. ونتيجة لذلك، يُمكن زيادة سرعة وتواتر تسليم برمجيات عالية الجودة (برمجيات تلبي توقعات مستوى مقبول من المخاطر)، بالإضافة إلى تقليل الديون التقنية . ^{[ 4 ] [ 10 ] [ 20 ]}

علاوة على ذلك، عندما تتوافق جهود ضمان جودة البرمجيات واختبارها مع توقعات العمل، ينتج عن تنفيذ الاختبار قائمة مُرتبة حسب الأولوية للمهام القابلة للتنفيذ (بدلاً من عدد هائل من النتائج التي قد تتطلب مراجعة يدوية). وهذا يساعد الفرق على تركيز جهودها على مهام الجودة التي سيكون لها أكبر الأثر، بناءً على أهداف مؤسستهم وأولوياتها. ^{[ 2 ]}

بالإضافة إلى ذلك، عندما تُجري الفرق باستمرار مجموعة واسعة من الاختبارات المتواصلة طوال دورة حياة تطوير البرمجيات، فإنها تجمع مقاييس تتعلق بجودة العملية وحالة البرنامج. ويمكن استخدام هذه المقاييس لإعادة فحص العملية نفسها وتحسينها، بما في ذلك فعالية تلك الاختبارات. ويمكن استخدام هذه المعلومات لإنشاء حلقة تغذية راجعة تساعد الفرق على تحسين العملية تدريجيًا. ^{[ 4 ] [ 10 ]} يُعد القياس المتكرر، وحلقات التغذية الراجعة الفعّالة، والتحسين المستمر من المبادئ الأساسية لمنهجية DevOps . ^{[ 21 ]}

يشمل الاختبار المستمر التحقق من صحة كل من المتطلبات الوظيفية والمتطلبات غير الوظيفية .

لاختبار المتطلبات الوظيفية ( الاختبار الوظيفي )، غالبًا ما يتضمن الاختبار المستمر اختبارات الوحدة ، واختبار واجهة برمجة التطبيقات ، واختبار التكامل ، واختبار النظام . أما لاختبار المتطلبات غير الوظيفية ( الاختبار غير الوظيفي - لتحديد ما إذا كان التطبيق يلبي التوقعات المتعلقة بالأداء والأمان والامتثال، وما إلى ذلك)، فيتضمن ممارسات مثل تحليل الكود الثابت ، واختبار الأمان ، واختبار الأداء ، وما إلى ذلك. ^{[ 9 ] [ 20 ]} ينبغي تصميم الاختبارات لتوفير الكشف المبكر (أو الوقاية) من المخاطر الأكثر أهمية للشركة أو المؤسسة التي تُصدر البرنامج. ^{[ 6 ]}

غالباً ما تجد الفرق أنه لضمان استمرارية عمل مجموعة الاختبارات وتقييم مستوى المخاطر بفعالية، من الضروري تحويل التركيز من اختبار واجهة المستخدم الرسومية إلى اختبار واجهة برمجة التطبيقات (API)، وذلك للأسباب التالية: 1) تُعتبر واجهات برمجة التطبيقات (طبقة المعاملات) الواجهة الأكثر استقراراً للنظام قيد الاختبار، و2) تتطلب اختبارات واجهة المستخدم الرسومية إعادة صياغة كبيرة لمواكبة التغييرات المتكررة التي تميز عمليات الإصدار السريع؛ بينما تكون الاختبارات على مستوى واجهة برمجة التطبيقات أقل عرضة للمشاكل وأسهل في الصيانة. ^{[ 11 ] [ 22 ] [ 23 ]}

تُجرى الاختبارات أثناء التكامل المستمر أو بالتزامن معه ، على الأقل يوميًا. ^{[ 24 ]} بالنسبة للفرق التي تُطبّق التسليم المستمر ، تُجرى الاختبارات عادةً عدة مرات في اليوم، في كل مرة يتم فيها تحديث التطبيق في نظام التحكم في الإصدار . ^{[ 9 ]}

من الناحية المثالية، تُجرى جميع الاختبارات على جميع بيئات الاختبار غير الإنتاجية . ولضمان الدقة والاتساق، ينبغي إجراء الاختبار في بيئة تحاكي بيئة الإنتاج قدر الإمكان. تشمل استراتيجيات تعزيز استقرار بيئة الاختبار برامج المحاكاة الافتراضية (للتبعيات التي يمكن لمؤسستك التحكم بها وإنشاء صور لها)، ومحاكاة الخدمات الافتراضية (للتبعيات التي تقع خارج نطاق تحكمك أو غير مناسبة لإنشاء صور لها)، وإدارة بيانات الاختبار. ^{[ 1 ] [ 4 ] [ 10 ] [ 25 ]}

• ينبغي أن يكون الاختبار ثمرة تعاون بين أقسام التطوير وضمان الجودة والعمليات ، بما يتماشى مع أولويات خط العمل ، وذلك ضمن عملية جودة منسقة وشاملة. ^{[ 1 ] [ 4 ] [ 10 ] [ 17 ] [ 26 ]}
• ينبغي أن تكون الاختبارات مُجزأة منطقياً، وتدريجية، وقابلة للتكرار؛ ويجب أن تكون النتائج حتمية وذات مغزى. ^{[ 1 ] [ 4 ]}
• يجب تشغيل جميع الاختبارات في مرحلة ما من مراحل عملية البناء، ولكن ليس من الضروري تشغيل جميع الاختبارات في كل مرة، لأن بعض الاختبارات تستهلك موارد أكثر ( اختبارات التكامل ) من غيرها (اختبارات الوحدة). ^{[ 1 ] [ 9 ]}
• إزالة قيود بيانات الاختبار وبيئة التشغيل لضمان تشغيل الاختبارات باستمرار وبشكل متسق في بيئات مشابهة لبيئات الإنتاج. ^{[ 1 ] [ 4 ] [ 9 ]}
• لتقليل النتائج الإيجابية الخاطئة، وتقليل صيانة الاختبارات، والتحقق من صحة حالات الاستخدام بشكل أكثر فعالية عبر الأنظمة الحديثة ذات البنى متعددة الطبقات، ينبغي على الفرق التركيز على اختبار واجهة برمجة التطبيقات (API) بدلاً من اختبار واجهة المستخدم الرسومية (GUI) . ^{[ 4 ] [ 11 ] [ 12 ]}

نظراً لأن التطبيقات الحديثة موزعة على نطاق واسع، فإن مجموعات الاختبار التي تُجري عليها الاختبارات تتطلب عادةً الوصول إلى تبعيات غير متاحة بسهولة للاختبار (مثل خدمات الطرف الثالث، وأجهزة الحاسوب المركزية التي لا تتوفر للاختبار إلا بقدرة محدودة أو في أوقات غير مناسبة، إلخ). علاوة على ذلك، مع تزايد اعتماد منهجيات التطوير الرشيقة والمتوازية، من الشائع أن تتطلب اختبارات الوظائف الشاملة الوصول إلى تبعيات لا تزال قيد التطوير أو لم تُنفذ بعد. يمكن معالجة هذه المشكلة باستخدام محاكاة الخدمات لمحاكاة تفاعلات التطبيق قيد الاختبار مع التبعيات المفقودة أو غير المتاحة. كما يمكن استخدامها لضمان اتساق البيانات والأداء والسلوك عبر مختلف عمليات تشغيل الاختبار. ^{[ 1 ] [ 7 ] [ 10 ]}

أحد أسباب تجنب الفرق للاختبار المستمر هو عدم كفاية قابلية توسع بنيتها التحتية لتنفيذ مجموعة الاختبارات بشكل متواصل. ويمكن معالجة هذه المشكلة من خلال تركيز الاختبارات على أولويات العمل، وتقسيم قاعدة الاختبار، وتنفيذ الاختبارات بالتوازي باستخدام أدوات أتمتة إصدار التطبيقات . ^{[ 24 ]}

يهدف الاختبار المستمر إلى تطبيق "أتمتة فائقة" على بيئات اختبار مستقرة تحاكي بيئة الإنتاج. الأتمتة ضرورية للاختبار المستمر. ^{[ 27 ]} لكن الاختبار الآلي ليس هو نفسه الاختبار المستمر. ^{[ 4 ]}

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

• في الاختبارات الآلية، قد يشير فشل الاختبار إلى أي شيء بدءًا من مشكلة حرجة وصولًا إلى انتهاك معيار تسمية بسيط. أما في الاختبارات المستمرة، فيشير فشل الاختبار دائمًا إلى خطر جسيم يهدد العمل.
• مع الاختبار المستمر، يتم التعامل مع فشل الاختبار من خلال سير عمل واضح لتحديد أولويات العيوب مقابل مخاطر العمل ومعالجة العيوب الأكثر أهمية أولاً.
• مع إجراء الاختبارات المستمرة، في كل مرة يتم فيها تحديد خطر ما، توجد آلية للكشف عن جميع العيوب المماثلة التي ربما تكون قد ظهرت بالفعل، بالإضافة إلى منع تكرار هذه المشكلة نفسها في المستقبل. ^{[ 2 ] [ 5 ]}

منذ تسعينيات القرن الماضي، استُخدم التطوير المستمر القائم على الاختبار لتزويد المبرمجين بتغذية راجعة سريعة حول ما إذا كان الكود الذي أضافوه يعمل بشكل صحيح، وما إذا كان قد غيّر أو عطّل وظائف موجودة دون قصد. يتضمن هذا الاختبار، الذي كان عنصرًا أساسيًا في البرمجة المتطرفة ، تنفيذ اختبارات الوحدة تلقائيًا (وأحيانًا اختبارات القبول أو الاختبارات الأولية) كجزء من عملية البناء الآلية، وغالبًا عدة مرات في اليوم. تُكتب هذه الاختبارات قبل التنفيذ؛ ويشير اجتيازها إلى نجاح التنفيذ. ^{[ 13 ] [ 28 ]}

• التسليم المستمر
• التكامل المستمر
• ديف أوبس
• إدارة الإصدارات
• محاكاة الخدمة
• اختبار البرمجيات
• أتمتة الاختبار

• أريولا، واين؛ دنلوب، سينثيا (2014). الاختبار المستمر . إنشاء مساحة. رقم ISBN 978-1494859756.
• جروفر، غاري؛ ماوزر، تومي (2015). قيادة التحول: تطبيق مبادئ أجايل وديف أوبس على نطاق واسع . دار نشر ثورة تكنولوجيا المعلومات. رقم ISBN 978-1942788010.
• ويتاكر، جيمس؛ أربون، جيسون؛ كارولو، جيف (2012). كيف تختبر جوجل البرمجيات . أديسون-ويسلي بروفيشنال. ISBN 978-0321803023.
• همبل، جيز؛ فارلي، ديفيد (2010). التسليم المستمر: إصدارات برمجيات موثوقة من خلال أتمتة البناء والاختبار والنشر . أديسون-ويسلي بروفيشنال. ISBN 978-0-321-60191-9.
• رادكليف، روزاليند (2021). اكتشاف الأخطاء في المؤسسات من خلال الاختبار والتكامل المستمر/التسليم المستمر لتحقيق نتائج الأعمال . دار نشر استراتيجيات التسريع. رقم ISBN 978-1-0983-8150-9. OCLC 1277049842 .