ما المقصود بالاختبار المبكر؟

هل سبق لك أن شاركت في مشروع برمجي تجاوز ميزانيته ولم يلتزم بأي من مواعيده النهائية؟ لا شك أنك مررت بذلك؛ فجميعنا مررنا به. في الواقع، إن لم تكن قد مررت بذلك، فأنت حالة نادرة، ويسعدني أن أسمع تجربتك.

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

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

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

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

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

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

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

يُعد نموذج V وسيلة مفيدة لتصور دورات تطوير البرمجيات. فعند أخذ المسار التقليدي لنموذج الشلال وعكس اتجاه المحور Y عند مرحلة التنفيذ، نحصل على نموذج V.

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

في منهجية الشلال، يمر المشروع بأكمله بدورة واحدة على شكل حرف «V». وقد أدركنا في هذا المجال أن تأجيل جميع عمليات التحقق إلى نهاية مشروع معقد يعني أنك، عمليًا، تحكم على المشروع بالفشل.

في العملية التكرارية، يمكن النظر إلى كل دورة تطوير قصيرة أو تكرار باعتبارها نموذج "V" مصغرًا. ومن الناحية النظرية، نكون بذلك قد حققنا هدفي الاختبار المبكر: إجراء الاختبارات في وقت أبكر وعلى نحو أكثر تكرارًا. إذن، حُلّت المشكلة، أليس كذلك؟ ليس تمامًا.

ربما لاحظت أن مسار التعليقات المضمّن في نموذج "V" يحمل تسميتين: التحقق من المطابقة والتحقق من الصلاحية. ولكلتا العمليتين أهمية بالغة.

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

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

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

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

تتحقق اختبارات واجهة برمجة التطبيقات من نقاط النهاية الخارجية لخدمة واحدة. ويتشابه نطاقها مع نطاق اختبارات التكامل، إلا أنه يمكن النظر إليها، في سياق البنية الموجهة نحو الخدمات (SOA) أو الخدمات المصغرة، باعتبارها الصورة الجديدة لاختبارات الوحدات.

تتحقق اختبارات واجهة المستخدم من الوظائف الكاملة للتطبيق عبر طبقة واجهة المستخدم. وتجعل أدوات مثل Selenium الاختبار المؤتمت لواجهات المستخدم متاحًا على نطاق واسع.

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

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

إذا اعتبرنا التطوير المدفوع بالاختبار (TDD) بمثابة «اختبار مبكر للبنى المتجانسة»، فإن الاختبار المستمر يمثّل "اختبارًا مبكرًا للبنى الموزعة".

دفعنا التطوير المدفوع بالاختبار (TDD) إلى التركيز على اختبار الوحدات. أما في الاختبار المستمر، فينبغي أن نركّز على اختبارات واجهة برمجة التطبيقات واختبارات العقود. تتميز اختبارات واجهة برمجة التطبيقات بعدة مزايا:

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

• يمكن أن يتولى الفريق المسؤول عن الخدمة نفسها مسؤولية اختبارات واجهة برمجة التطبيقات.
   

• تتجنب اختبارات واجهة برمجة التطبيقات هشاشة الاختبارات التي تعتمد على الآثار الجانبية وتفاصيل التنفيذ.

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

ماذا لو تمكّنا من استخدام الاختبار المستمر لواجهات برمجة التطبيقات والمدمج في أداة قابلية الملاحظة لدينا؟ ستتيح لك ميزة اختبار واجهة برمجة التطبيقات الاصطناعي المتوفرة في Instana إجراء اختبارات واجهة برمجة التطبيقات باستمرار لجميع بيئاتك بأقل جهد ممكن.

يتضمن الاختبار المبكر نقل أنشطة الاختبار إلى مرحلة أقرب من بداية دورة حياة تطوير البرمجيات، ما يُتيح الحصول على تقييمات أسرع ويقلِّل من الوقت والجهد المطلوبين لإصلاح الأخطاء. فيما يلي بعض أفضل الممارسات للاختبار المبكر في تطوير التطبيقات المرنة:

1. المشاركة المبكرة: يجب أن تبدأ أنشطة الاختبار في أقرب وقت ممكن في عملية التطوير. يجب أن يشارك منفِّذو الاختبارات بدءًا من مرحلة جمع المتطلبات لفهم نطاق المشروع وأهدافه وتوقعات المستخدمين.
    

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

3. أتمتة الاختبارات: استثمر في أتمتة الاختبار لتمكين إجراء اختبارات متكررة وفعَّالة. ينبغي إنشاء الاختبارات الآلية جنبًا إلى جنب مع عملية التطوير ودمجها في مسارات التكامل والنشر المستمرين. ويساعد هذا على اكتشاف العيوب في وقت مبكر، وتقليل مشكلات الانحدار، وتسريع دورات التعليقات.
    

4. تطوير البرمجيات المدفوع بالاختبار (TDD): تشجيع ممارسة TDD، حيث يقوم المطورون بكتابة حالات الاختبار قبل كتابة التعليمات البرمجية الفعلية. يساعد نهج الاختبار المبكر هذا على تحديد السلوك المطلوب والنتائج المتوقعة منذ البداية، مما يؤدي إلى تعليمات برمجية أكثر متانة وقابلية للاختبار.
    

5. التكامل المستمر والتسليم المستمر (CI/CD): طبّق مسارات CI/CD لأتمتة عمليات بناء البرمجيات واختبارها ونشرها. وتضمن هذه الممارسة اختبار كل تغيير في التعليمات البرمجية اختبارًا شاملًا ونشره في بيئات الإنتاج بسرعة وعلى نحو متكرر، مما يقلل مخاطر حدوث مشكلات في التكامل.
    

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

7. الاختبار الاستكشافي: شجّع إجراء الاختبارات الاستكشافية إلى جانب الاختبارات المؤتمتة، لفحص التطبيق من منظور المستخدم. يستطيع المختبرون ذوو الخبرة تحديد مشكلات قابلية الاستخدام المحتملة، والحالات الحدّية، والسيناريوهات التي قد لا ترصدها الاختبارات المؤتمتة.
    

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

9. بيئات الاختبار وبياناته: هيّئ بيئات اختبار تحاكي بيئات الإنتاج قدر الإمكان لضمان اختبار البرمجيات في ظروف واقعية. وتأكد أيضًا من توافر بيانات اختبار كافية وممثلة للواقع لمحاكاة سيناريوهات الاستخدام الفعلية.
    

10. التعلم والتحسين المستمران: عزّز ثقافة التعلم والتحسين المستمرين. وشجّع إجراء مراجعات دورية لعمليات الاختبار، وتحديد الاختناقات، وتنفيذ التغييرات اللازمة لتعزيز فاعلية الاختبار المبكر.

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

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

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

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

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

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

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

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

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

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

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

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

يمثّل الاختبار الاصطناعي لواجهات برمجة التطبيقات، ضمن منصة قابلية الملاحظة، وسيلة مثالية للجمع بين مزايا الاختبار المبكر والاختبار المتأخر.