تعرَّف على كيفية الجمع بين أنواع الاختبارات المختلفة في استراتيجية معقولة تتناسب مع مشروعك.
أهلاً بك من جديد. تناولت المقالة الأخيرة الكثير من الأساسيات حول كيفية التعامل مع أنواع الاختبارات المختلفة ومحتواها، كما وضّحت تعريفات أنواع الاختبارات. هل تتذكّرون صورة الميم الصغيرة هذه؟ ربما تساءلت عن كيفية عمل جميع أنواع الاختبارات التي تعرّفت عليها معًا.
بعد ذلك، ستتعلم ذلك بالضبط. تقدّم هذه المقالة مقدمة حول كيفية دمج أنواع الاختبارات هذه في استراتيجيات معقولة واختيار استراتيجية تتطابق مع مشروعك.
يمكنك مقارنة الاستراتيجيات بعدد من الأشكال لفهم معناها بشكل أفضل. في ما يلي قائمة بالاستراتيجيات مع أحجامها ونطاقات تطويرها.
لنتعرّف أكثر على الاستراتيجيات ومعاني أسمائها.
تحديد أهداف الاختبار: ما الذي تريد تحقيقه من خلال هذه الاختبارات؟
قبل البدء في وضع استراتيجية جيدة، حدِّد هدف الاختبار. متى تعتبر أنّ تطبيقك قد تم اختباره بشكل كافٍ؟
غالبًا ما يُعتبر تحقيق تغطية اختبار عالية هو الهدف الأسمى للمطوّرين في ما يتعلّق بالاختبار. ولكن هل هو دائمًا أفضل نهج؟ قد يكون هناك عامل مهم آخر يجب مراعاته عند تحديد استراتيجية الاختبار، وهو تلبية احتياجات المستخدمين.
بصفتك مطوّرًا، يمكنك أيضًا استخدام العديد من التطبيقات والأجهزة الأخرى. في هذا الصدد، أنت المستخدم الذي يعتمد على كل هذه الأنظمة لـ "العمل فقط". في المقابل، أنت تعتمد على عدد لا يحصى من المطورين لبذل قصارى جهدهم لجعل تطبيقاتهم وأجهزتهم تعمل. ولتحقيق ذلك، عليك كمطوّر أن تسعى أيضًا إلى أن تكون على قدر هذه الثقة. لذلك، يجب أن يكون هدفك الأول دائمًا هو توفير برامج تعمل بشكل جيد وتخدم المستخدمين. وينطبق ذلك أيضًا على الاختبارات التي تكتبها لضمان جودة التطبيق. كينت س. Dodds في منشوره Static vs Unit vs Integration vs E2E Testing for Frontend Apps:
كلما زاد تشابه اختباراتك مع طريقة استخدام برنامجك، زادت الثقة التي يمكن أن تمنحها لك.
بقلم "كينت سي" Dodds
يصف "كينت" ذلك بأنّه اكتساب الثقة في الاختبارات. كلما اقتربت من المستخدمين عن طريق اختيار نوع اختبار مناسب، زادت ثقتك في اختباراتك للحصول على نتائج صحيحة. بعبارة أخرى، كلما صعدت إلى أعلى الهرم، زادت ثقتك بنفسك. ولكن ما هو الهرم؟
تحديد استراتيجيات الاختبار: كيفية اختيار استراتيجية الاختبار
كخطوة أولى، حدِّد أجزاء المتطلبات التي تحتاج إلى التحقّق منها للتأكّد من استيفائها. تعرَّف على أنواع الاختبارات التي يجب استخدامها ومستوى التفاصيل الذي يمكنك من خلاله تحقيق أعلى مستوى من الثقة مع الحفاظ على بنية تكلفة فعّالة. يتناول العديد من المطوّرين هذا الموضوع باستخدام المقارنات. في ما يلي أكثرها شيوعًا، بدءًا من الكلاسيكية المعروفة.
النموذج الكلاسيكي: هرم الاختبار
بمجرد أن تبدأ في البحث عن استراتيجيات الاختبار، من المحتمل أن تصادف هرم أتمتة الاختبار كأول تشبيه. قدّم "مايك كون" هذا المفهوم في كتابه "Succeeding with Agile". لاحقًا، توسّع "مارتن فاولر" في هذا المفهوم في مقالته هرم الاختبار العملي. يمكنك تمثيل الهرم بصريًا على النحو التالي:
كما هو موضّح في هذا الرسم، يتكوّن هرم الاختبار من ثلاث طبقات:
الوحدة: تجد هذه الاختبارات في الطبقة الأساسية من الهرم لأنها سريعة التنفيذ وسهلة الصيانة. وهي معزولة وتستهدف أصغر وحدات الاختبار. على سبيل المثال، يمكنك الاطّلاع على اختبار وحدة نموذجي لمنتج صغير جدًا.
الدمج: تقع هذه الاختبارات في منتصف الهرم، لأنّها تتميز بسرعة تنفيذ مقبولة ولكنّها تقرّبك من المستخدم أكثر من اختبارات الوحدات. ومن الأمثلة على اختبارات الدمج اختبار واجهة برمجة التطبيقات. يمكنك أيضًا تصنيف اختبارات المكوّنات على أنّها من هذا النوع.
اختبارات شاملة (تُعرف أيضًا باسم اختبارات واجهة المستخدم) تحاكي هذه الاختبارات مستخدمًا حقيقيًا وتفاعله. وتحتاج هذه الاختبارات إلى مزيد من الوقت لتنفيذها، وبالتالي تكون أكثر تكلفة. إنّهم في أعلى الهرم.
الثقة مقابل الموارد
كما ذكرنا سابقًا، فإنّ ترتيب الطبقات ليس من قبيل الصدفة. وهي تعرض الأولويات والتكاليف المقابلة لها. يمنحك هذا صورة واضحة عن عدد الاختبارات التي يجب كتابتها لكل طبقة. لقد رأيت هذا بالفعل في تعريف أنواع الاختبار.
نظرًا لأن اختبارات E2E هي الأقرب إلى المستخدمين، فإنها تمنحك أكبر قدر من الثقة في أن تطبيقك يعمل على النحو المنشود. ومع ذلك، فهي تتطلب حزمة تطبيق كاملة ومستخدمًا محاكيًا، وبالتالي، من المحتمل أيضًا أن تكون الأكثر تكلفة. لذلك، فإنّ الثقة في منافسة مباشرة مع الموارد التي تحتاجها لتنفيذ الاختبارات.
يحاول الهرم حل هذه المشكلة من خلال جعلك تركز أكثر على اختبارات الوحدة وتحديد أولويات الحالات التي تغطيها اختبارات E2E بشكل صارم. على سبيل المثال، تجارب المستخدمين الأكثر أهمية أو الأماكن الأكثر عرضة للعيوب. كما يؤكد "مارتن فاولر"، فإنّ أهم نقطتَين في هرم "كون" هما:
- كتابة اختبارات بمستويات دقة مختلفة
- كلما ارتفع المستوى الذي تصل إليه، قلّ عدد الاختبارات التي يجب أن تجريها.
تطوّر الهرم! تعديلات على أهرامات الاختبار
على مدار عدة سنوات، دارت المناقشات حول الهرم. يبدو أنّ الهرم يفرط في تبسيط استراتيجيات الاختبار، ويستبعد الكثير من أنواع الاختبارات، ولم يعُد يناسب جميع المشاريع الواقعية. وبالتالي، قد تكون مضلِّلة. هل فقد الهرم شكله؟ Guillermo Rauch has an opinion about it:
كتابة الاختبارات ليس كثيرًا. في الغالب التكامل.
بقلم "غييرمو راوش"
إنّه أحد أكثر الاقتباسات شيوعًا حول هذا الموضوع، لذا دعونا نحلّله:
- "كتابة الاختبارات" ليس فقط لأنّه يبني الثقة، بل لأنّه يوفّر الوقت في الصيانة أيضًا.
- "ليس كثيرًا". لا تكون التغطية بنسبة %100 جيدة دائمًا لأنّ الاختبارات لن تكون ذات أولوية وسيكون هناك الكثير من أعمال الصيانة.
- "Mostly integration" (الدمج في الغالب) وهنا أيضًا، يتم التركيز على اختبارات التكامل: فهي تتمتع بأعلى قيمة تجارية من خلال منحك مستوى ثقة يوميًا عاليًا مع الحفاظ على وقت تنفيذ معقول.
يدفعك ذلك إلى إعادة التفكير في هرم الاختبار وتحويل تركيزك إلى اختبار التكامل. على مدار السنوات القليلة الماضية، تم اقتراح العديد من التعديلات، لذا دعونا نلقي نظرة على أكثرها شيوعًا.
اختبار الألماس
يزيل التعديل الأول التركيز المفرط على اختبار الوحدة، كما هو موضح في هرم الاختبار. لنفترض أنّك حقّقت تغطية بنسبة %100 في اختبارات الوحدات. ومع ذلك، في المرة التالية التي تقوم فيها بإعادة البناء، سيتعين عليك تحديث العديد من اختبارات الوحدة هذه وقد تميل إلى تخطيها. لذلك تتآكل.
نتيجة لذلك، وإلى جانب التركيز الأعلى على اختبار التكامل، قد ينشأ الشكل التالي:
يتحوّل الهرم إلى شكل ماسة. يمكنك رؤية الطبقات الثلاث السابقة، ولكن بحجم مختلف، وتم قطع طبقة الوحدة:
- الوحدة: اكتب اختبارات الوحدة بالطريقة التي حدّدتها سابقًا. ومع ذلك، نظرًا لأنها تميل إلى التآكل، حدد أولويات الحالات الأكثر أهمية فقط وقم بتغطيتها.
- الدمج: اختبارات التكامل التي تعرفها، والتي تختبر مجموعة من الوحدات الفردية.
- E2E: تتعامل هذه الطبقة مع اختبارات واجهة المستخدم بشكل مشابه لهرم الاختبار. يُرجى الحرص على كتابة اختبارات شاملة لأُطر الاختبار الأكثر أهمية فقط.
اختبار قرص العسل
هناك تعديل آخر، قدّمته Spotify، يشبه شكل الألماس في الاختبار ولكنه أكثر تخصّصًا لأنظمة البرامج المستندة إلى الخدمات المصغّرة. يُعدّ اختبار خلية النحل تشبيهًا مرئيًا آخر لدقة الاختبارات ونطاقها وعددها التي يجب كتابتها لنظام برامج قائم على الخدمات المصغّرة. نظرًا لصغر حجمها، فإن التعقيد الأكبر في الخدمة المصغرة ليس داخل الخدمة نفسها، ولكن في كيفية تفاعلها مع الآخرين. لذلك، يجب أن تركّز استراتيجية اختبار الخدمة المصغّرة بشكل أساسي على اختبارات الدمج.
يذكّرنا هذا الشكل بقرص العسل، ومن هنا جاء الاسم. ويتضمّن الطبقات التالية:
- الاختبارات المتكاملة: تستخدم المقالة التي نشرتها Spotify اقتباسًا من J. ب. Rainsberger لتعريف هذه الطبقة: "اختبار ينجح أو يفشل بناءً على صحة نظام آخر". تحتوي هذه الاختبارات على تبعيات خارجية يجب مراعاتها، وعلى العكس من ذلك، قد يكون نظامك تبعية تؤدي إلى تعطيل الأنظمة الأخرى. على غرار اختبارات E2E في القياسات الأخرى، استخدِم هذه الاختبارات بعناية، فقط في الحالات الأكثر أهمية.
- اختبارات التكامل: على غرار عمليات التكييف الأخرى، يجب التركيز على هذه الطبقة. وهي تحتوي على اختبارات تتحقّق من صحة الخدمة بطريقة أكثر عزلة، ولكن مع خدمات أخرى. وهذا يعني أنّ الاختبارات ستشمل بعض الأنظمة الأخرى أيضًا وستركّز على نقاط التفاعل، على سبيل المثال، من خلال اختبارات واجهة برمجة التطبيقات.
- الاختبارات على تفاصيل التنفيذ: تشبه هذه الاختبارات اختبارات الوحدات، وهي اختبارات تركّز على أجزاء من الرمز البرمجي تكون معزولة بشكل طبيعي وبالتالي لها تعقيدها الداخلي الخاص.
إذا أردت معرفة المزيد عن استراتيجية الاختبار هذه، يمكنك الاطّلاع على المنشور الذي يقارن بين هرم الاختبار وقرص العسل بقلم "مارتن فاولر" والمقالة الأصلية من Spotify.
كأس الاختبار
يمكنك بالفعل رؤية تركيز متكرر على اختبارات التكامل. ومع ذلك، هناك نوع آخر صادفته في المقالة السابقة ليس اختبارًا من الناحية النظرية ولكنه لا يزال جانبًا مهمًا يجب مراعاته في استراتيجية الاختبار. التحليل الثابت مفقود من هرم الاختبار وفي معظم التعديلات التي رأيتها حتى الآن. هناك نموذج "كأس الاختبار" (testing trophy) الذي يأخذ التحليل الثابت في الاعتبار مع التركيز على اختبارات الدمج. يعود أصل كأس الاختبار إلى الاقتباس السابق الذي ذكره "غييرمو راوخ"، وقد طوّره "كينت سي". Dodds:
كأس الاختبار هو تشبيه يوضّح دقة الاختبارات بطريقة مختلفة قليلاً. ويتكوّن من أربع طبقات:
- التحليل الثابت: فهو يؤدي دورًا حيويًا في هذا التشبيه ويتيح لك اكتشاف الأخطاء الإملائية وأخطاء الأسلوب والأخطاء الأخرى بمجرد تنفيذ خطوات تصحيح الأخطاء الموضحة سابقًا.
- اختبارات الوحدات: فهي تضمن اختبار أصغر وحدة بشكل مناسب، ولكن كأس الاختبار لن يؤكد عليها بنفس القدر مثل هرم الاختبار.
- الدمج: هذا هو التركيز الرئيسي لأنه يوازن بين التكلفة والثقة الأعلى بأفضل طريقة، كما هو الحال مع التعديلات الأخرى.
- اختبارات واجهة المستخدم: بما في ذلك الاختبارات الشاملة والاختبارات المرئية، فهي تقع في أعلى كأس الاختبار، على غرار دورها في هرم الاختبار.
لمزيد من المعلومات حول كأس الاختبار، يمكنك الاطّلاع على منشور المدوّنة الذي كتبه "كينت سي. Dodds حول هذا الموضوع.
بعض الأساليب التي تركّز أكثر على واجهة المستخدم
هذا كله جيد، ولكن بغض النظر عن الطريقة التي تسمي بها استراتيجيتك، سواء كانت "هرمية" أو "قرص عسل" أو "ألماسية"، لا يزال هناك شيء مفقود. على الرغم من أنّ أتمتة الاختبارات مفيدة، من المهم تذكُّر أنّ الاختبار اليدوي لا يزال ضروريًا. يجب أن يخفف الاختبار الآلي من المهام الروتينية ويحرر مهندسي ضمان الجودة للتركيز على المجالات المهمة. بدلاً من استبدال الاختبار اليدوي، يجب أن يكمّله التشغيل الآلي. هل هناك طريقة لدمج الاختبار اليدوي مع التشغيل الآلي للحصول على أفضل النتائج؟
اختبار مخروط الآيس كريم واختبار السلطعون
هناك بالفعل تعديلان على هرم الاختبار يركزان أكثر على طرق الاختبار التي تركز على واجهة المستخدم. يتمتع كلاهما بميزة الثقة العالية، ولكنهما بطبيعة الحال أكثر تكلفة بسبب بطء تنفيذ الاختبار.
الأول، مخروط الجليد التجريبي، يشبه الهرم في الاتجاه المعاكس. بدون خطوة الاختبار اليدوي، يُعرف أيضًا باسم بيتزا الاختبار.
يركز مخروط الثلج بشكل أكبر على الاختبار اليدوي أو اختبار واجهة المستخدم وأقل تركيز على اختبار الوحدة. غالبًا ما يتشكل في المشاريع التي بدأ فيها المطورون العمل ببضع أفكار فقط حول استراتيجية الاختبار. يُعتبر الرمز البرمجي المجمّد نمطًا مضادًا، وهذا صحيح، لأنّه مكلف من حيث الموارد والعمل اليدوي.
يشبه اختبار السلطعون اختبار مخروط الثلج، ولكن مع التركيز بشكل أكبر على الاختبار الشامل والاختبار المرئي:
تتضمّن استراتيجية الاختبار هذه جانبًا آخر: فهي تتحقّق من أنّ تطبيقك يعمل بشكل جيد ويبدو جيدًا. يسلّط اختبار السلطعون الضوء على أهمية الاختبار المرئي، المحدّد في المقالة السابقة. أما اختبار التكامل، الذي ينقسم إلى اختبار المكوّنات واختبار واجهة برمجة التطبيقات، فينتقل إلى الخلفية، ويلعب اختبار الوحدات دورًا ثانويًا أكبر هنا. يمكنك العثور على مزيد من التفاصيل حول استراتيجية الاختبار هذه في هذه المقالة حول اختبار السلطعون.
على الرغم من أنّ هاتين الاستراتيجيتين أكثر تكلفة، إلا أنّهما مفيدتان في بعض الحالات، مثل المشاريع الصغيرة التي تتطلّب عددًا أقل من الاختبارات أو التي تكون أقل تعقيدًا. في هذه الحالة، قد تكون استراتيجية الاختبار الكاملة التي تركّز على اختبار الدمج مبالغًا فيها.
على الرغم من أنّ هاتين الاستراتيجيتين للاختبار أكثر تكلفة، إلا أنّهما مفيدتان، على سبيل المثال، في المشاريع الأصغر حجمًا التي تتطلّب عددًا أقل من الاختبارات ولا تحتاج إلى تغطية الكثير من التعقيدات. في هذه الحالة، قد تكون استراتيجية الاختبار واسعة النطاق التي تركز على اختبار التكامل معقدة دون داعٍ.
نصائح عملية: لنضع استراتيجية!
لقد تعرّفت الآن على استراتيجيات الاختبار الأكثر شيوعًا. لقد بدأت بالنموذج الكلاسيكي، وهو هرم الاختبار، وتعرّفت على أشكاله المتعددة. الآن عليك تقييمها لمنتجك وتحديد أي منها سيكون الأفضل لمشروعك. يجب أن تبدأ الإجابة عن هذا السؤال بالعبارة المفضّلة لدى الجميع: "يعتمد ذلك على عدة عوامل". ومع ذلك، لا يقلل ذلك من دقتها.
يعتمد اختيار استراتيجية الاختبار الأنسب من بين الاستراتيجيات الموضحة - وحتى تلك التي تم استبعادها - على تطبيقك. يجب أن يتناسب مع بنيتك ومتطلباتك، وأخيرًا وليس آخرًا، مع المستخدمين ومتطلباتهم. قد يختلف كل هذا من تطبيق إلى آخر. فهذا أمر طبيعي تمامًا. تذكَّر أنّ هدفك الأهم هو خدمة المستخدمين، وليس الالتزام بتعريف حرفي.
في أغلب الأحيان، يصعب فصل اختبارات العالم الحقيقي وتحديدها بشكل فردي. حتى "مارتن فاولر" نفسه يؤكد على الجانب الإيجابي للتعريفات المختلفة، كما هو الحال في اختبارات الوحدات. كما يذكر جاستن سيرلز بشكل صحيح في تغريدته:
[…] كتابة اختبارات معبّرة تضع حدودًا واضحة، وتعمل بسرعة وبشكل موثوق، ولا تفشل إلا لأسباب مفيدة.
بقلم "جاستن سيرلز"
ركِّز على الاختبارات التي تبلّغ عن أخطاء فعلية قد يواجهها المستخدمون، ولا تشتّت انتباهك عن هدفك. يجب تصميم الاختبارات لإفادة المستخدم، وليس فقط لتوفير تغطية بنسبة %100 أو لمناقشة النسبة المئوية لنوع الاختبار الذي يجب كتابته.
ركِّز على الاختبارات التي تبلّغ عن أخطاء حقيقية قد يواجهها المستخدمون، ولا تشتّت انتباهك عن هدفك. يجب تصميم الاختبارات لإفادة المستخدم، وليس فقط لتوفير تغطية بنسبة %100 أو إثارة النقاشات حول النسبة المئوية لنوع اختبار معيّن يجب كتابته.