اكتشف كيفية دمج أنواع الاختبار المختلفة في استراتيجية معقولة تتوافق مع مشروعك.
تسرّنا عودتك. وضعت المقالة الأخيرة الكثير من الأساسيات حول كيفية التعامل مع أنواع الاختبارات المختلفة وما تتضمّنها تلك الأنواع، كما أوضحت تعريفات أنواع الاختبار. هل تذكّرت هذه الصورة الصغيرة المضحكة؟ ربما تساءلت كيف يمكن أن تعمل كل أنواع الاختبار التي تعلمتها معًا.
بعد ذلك، ستتعلم ذلك بالضبط. تقدم هذه المقالة مقدمة حول كيفية دمج أنواع الاختبار هذه في استراتيجيات معقولة واختيار واحدة تتناسب مع مشروعك.
يمكنك مقارنة الاستراتيجيات بعدد من الأشكال لفهم معناها بشكل أفضل. في ما يلي قائمة بالاستراتيجيات التي تتضمّن أحجامًا ونطاقات تطوير ذات صلة.
لنلقِ نظرة فاحصة على هذه الاستراتيجيات ونتعرف على معنى أسمائها.
تحديد أهداف الاختبار: ما الذي تريد تحقيقه من خلال هذه الاختبارات؟
قبل أن تتمكن من البدء في بناء استراتيجية جيدة، حدد هدفك من الاختبار. متى تعتبر أنّ تطبيقك قد تم اختباره بشكل كافٍ؟
غالبًا ما يُعتبر تحقيق تغطية عالية للاختبارات هو الهدف النهائي للمطوّرين في ما يتعلّق بالاختبار. ولكن هل هو دائمًا النهج الأفضل؟ قد يكون هناك عامل مهم آخر يجب مراعاته عند اتخاذ قرار بشأن استراتيجية الاختبار، وهو تلبية احتياجات المستخدمين.
بصفتك مطورًا، يمكنك أيضًا استخدام العديد من التطبيقات والأجهزة الأخرى. وفي هذا الصدد، أنت المستخدم الذي يعتمد على جميع هذه الأنظمة "مجرد العمل"، وفي المقابل، أنت تعتمد على عدد لا يحصى من المطوّرين لبذل قصارى جهدهم لضمان نجاح تطبيقاتهم وأجهزتهم. لتغيير هذا الأمر مرة أخرى، كمطوّر، فإنّك تسعى أيضًا جاهدًا لترتقي بهذه الثقة. لذلك يجب أن يكون هدفك الأول دائمًا هو شحن برامج العمل وخدمة المستخدمين. ويشمل ذلك الاختبارات التي تكتبها لضمان جودة التطبيق. كينت سي. يلخصها فريق Dodds بشكل جيد جدًا في المشاركة التي شاركها ثابت مقابل الوحدة الثابتة مقابل الدمج مقابل الاختبار E2E لتطبيقات الواجهة الأمامية:
وكلما تشابهت اختباراتك بطريقة استخدام برنامجك، زادت الثقة التي يمكن أن يمنحك إياها.
بواسطة كينت سي. فريق Dodds
يصف كينت الأمر بأنه يكتسب الثقة في الاختبارات. كلما اقتربت من المستخدمين عن طريق اختيار نوع اختبار مناسب، زادت ثقتك في اختباراتك للحصول على نتائج صالحة. بمعنى آخر، كلما تسلقت الهرم إلى أعلى، زادت ثقتك فيك. ولكن انتظر، ما هو الهرم؟
تحديد استراتيجيات الاختبار: كيفية اختيار استراتيجية الاختبار
كخطوة أولى، حدد أجزاء المتطلبات التي تحتاج إلى التحقق منها للتأكد من استيفائها. اكتشف أنواع الاختبارات التي يجب استخدامها وعلى أي مستوى من التفاصيل يمكنك تحقيق أكبر قدر من الثقة مع الحفاظ على بنية فعالة للتكلفة. يتعامل العديد من المطورين مع هذا الموضوع باستخدام المقارنات. إليك أكثرها شيوعًا، بدءًا من الكلاسيكيات الشهيرة.
الكلاسيكي: هرم الاختبار
بعد أن تبدأ في البحث عن استراتيجيات الاختبار، من المحتمل أن تصادف هرم أتمتة الاختبار باعتباره أول تشبيه. قدم مايك كوهن هذا المفهوم في كتابه "النجاح باستخدام أجايل". في وقت لاحق، وسّع "مارتن فاولر" هذا المفهوم في مقالته هرم الاختبار العملي. يمكنك تمثيل الهرم بشكل مرئي على النحو التالي:
وكما هو موضح في هذا الرسم، يتكون هرم الاختبار من ثلاث طبقات:
الوحدة: تجد هذه الاختبارات في الطبقة الأساسية من الهرم لأنها سريعة التنفيذ وسهلة الصيانة. وهي معزولة وتستهدف وحدات الاختبار الأصغر حجمًا. على سبيل المثال، يمكنك الاطّلاع على اختبار وحدة نموذجي لمنتج صغير جدًا.
الدمج: تقع هذه الاختبارات في وسط الهرم، لأنّها تتميز بسرعة تنفيذ مقبولة، ولكنّها تقرِّبك أكثر من المستخدم عن تلك التي يمكن إجراءها لاختبارات الوحدة. ومن الأمثلة على اختبار الدمج إجراء اختبار واجهة برمجة التطبيقات. يمكنك أيضًا تصنيف اختبارات المكوّنات حسب هذا النوع.
اختبارات E2E (تسمى أيضًا اختبارات واجهة المستخدم). تحاكي هذه الاختبارات مستخدمًا حقيقيًا وتفاعله. يحتاج تنفيذ هذه الاختبارات إلى مزيد من الوقت، وبالتالي فهي أكثر تكلفة. تقع في أعلى الهرم.
الثقة مقابل الموارد
وكما تم تناوله بإيجاز من قبل، فإن ترتيب الطبقات ليس مصادفة. وهي تعرض الأولويات والتكاليف المقابلة لها. يمنحك هذا صورة واضحة عن عدد الاختبارات التي يجب عليك كتابتها لكل طبقة. وقد اطّلعت على ذلك من قبل في تعريف أنواع الاختبار.
وبما أنّ اختبارات E2E هي أقرب ما يكون إلى المستخدمين، فهي تمنحك أكبر قدر من الثقة بأن تطبيقك يعمل على النحو المنشود. ومع ذلك، فهي تتطلب حزمة تطبيقات كاملة ومستخدم محاكى، وبالتالي، قد تكون أيضًا الأكثر تكلفة. لذا فإن الثقة في منافسة مباشرة مع الموارد التي تحتاجها لتنفيذ الاختبارات.
يحاول التسلسل الهرمي حلّ هذه المشكلة من خلال التركيز بشكل أكبر على اختبارات الوحدات مع منح الأولوية بشكل صارم للحالات التي تشملها اختبارات E2E. على سبيل المثال، رحلات المستخدم الأكثر أهمية أو الأماكن الأكثر عُرضة للعيوب. كما يؤكد مارتن فاولر، فإن أهم نقطتين أساسيتين في هرم كوهن هما ما يلي:
- كتابة الاختبارات بدرجات دقة مختلفة
- كلما حصلت على مستوى أعلى، قل عدد الاختبارات التي يمكنك إجراؤها.
تطوّر الهرم اقتباسات من أهرامات الاختبار
على مدار سنوات عديدة، دارت المناقشات حول الهرم. يبدو أن الهرم يفرط في تبسيط استراتيجيات الاختبار، ويتجاهل الكثير من أنواع الاختبارات، ولم يعد يناسب جميع مشاريع العالم الحقيقي. لذلك، فقد يكون مضللاً. هل سقط الهرم عن غيره من الأشكال؟ رأي Guillermo Rauch في هذا الموضوع:
كتابة الاختبارات. ليس كبيرًا جدًا. الدمج في الغالب
من تأليف "جييرمو راوش"
إنه أحد الاقتباسات الأكثر شيوعًا حول هذا الموضوع، لذا دعنا نحلله:
- "كتابة الاختبارات". ليس فقط لأنه يبني الثقة، ولكن أيضًا لأنه يوفر وقت الصيانة.
- "ليس كبيرًا جدًا". التغطية بنسبة 100% ليست جيدة دائمًا لأنه لن يتم إعطاء الأولوية للاختبار وسيكون هناك الكثير من الصيانة.
- "التكامل في الغالب". ومرةً أخرى، ينصب التركيز على اختبارات التكامل: فهي تحقّق أكبر قيمة تجارية من خلال منحك مستوى ثقة عالٍ يوميًا مع الحفاظ على وقت تنفيذ معقول.
وهذا يجعلك تفكر مرة أخرى في هرم الاختبار وتحويل تركيزك إلى اختبار الدمج. على مدار السنوات القليلة الماضية، تم اقتراح العديد من عمليات التعديل، لذلك دعونا نلقي نظرة على أكثرها شيوعًا.
معيّن تجريبي
يزيل التعديل الأول التوكيد الزائد على اختبار الوحدة، كما يظهر في هرم الاختبار. تخيل أنك وصلت إلى تغطية 100% في اختبارات الوحدات. ومع ذلك، في المرة القادمة التي تقوم فيها بإعادة الهيكلة، سيتعين عليك تحديث العديد من اختبارات الوحدات هذه، وقد تميل إلى تخطيها. لذلك تتآكل.
ونتيجةً لذلك، ومع التركيز الأكبر على اختبار التكامل، قد يظهر الشكل التالي:
يتحوّل الهرم إلى ماسة. يمكنك رؤية الطبقات الثلاث السابقة، ولكن بحجم مختلف، وقد تم قطع طبقة الوحدة:
- الوحدة: اكتب اختبارات الوحدات بالطريقة التي حددتها من قبل. ومع ذلك، لأنها تميل إلى التآكل، وتحديد أولوياتها وتغطية الحالات الأكثر أهمية فقط.
- الدمج: اختبارات الدمج التي تعرفها، واختبار مجموعة الوحدات المفردة.
- E2E: تتعامل هذه الطبقة مع اختبارات واجهة المستخدم المشابهة لهرم الاختبار. احرص على كتابة اختبارات E2E فقط في حالات الاختبارات الأكثر أهمية.
اختبار خلية النحل
هناك تعديل آخر طرحته Spotify يشبه ألماس الاختبار ولكنّه متخصّص أكثر في أنظمة البرامج المستندة إلى الخدمات الدقيقة. يعتبر اختبار خلية النحل بمثابة تشبيه مرئي آخر للدقة والنطاق وعدد الاختبارات المراد كتابتها لنظام برامج مستند إلى الخدمات الدقيقة. وبسبب حجم هذه الخدمات الصغيرة، لا يكون التعقيد الأكبر في الخدمة الصغرى ضمن الخدمة نفسها، بل في كيفية تفاعلها مع الآخرين. لذلك، يجب أن تركّز استراتيجية الاختبار للخدمة الصغيرة بشكل أساسي على اختبارات الدمج.
هذا الشكل يذكرنا بقرص عسل، ومن ثم الاسم. وهي تحتوي على الطبقات التالية:
- الاختبارات المدمجة: تستخدم المقالة من Spotify اقتباسًا من J. B. في تعريف هذه الطبقة: "اختبار سيجتاز أو يفشل بناءً على صحة نظام آخر". ولهذه الاختبارات تبعيات خارجية عليك أخذها في الاعتبار، وعلى العكس من ذلك، قد يكون نظامك تبعية تؤدي إلى تعطّل الأنظمة الأخرى. وعلى غرار اختبارات E2E في التشابهات الأخرى، استخدم هذه الاختبارات بعناية، للحالات الأكثر أهمية فقط.
- اختبارات الدمج: وعلى غرار التعديلات الأخرى، يجب أن تركز على هذه الطبقة. ويحتوي هذا البرنامج على اختبارات تؤكّد صحة خدمتك بطريقة أكثر عزلة، ولكن لا تزال جنبًا إلى جنب مع خدمات أخرى. وهذا يعني أنّ الاختبارات ستشمل بعض الأنظمة الأخرى أيضًا، وستركّز على نقاط التفاعل، من خلال اختبارات واجهة برمجة التطبيقات مثلاً.
- اختبارات على تفاصيل التنفيذ: تشبه هذه الاختبارات اختبارات الوحدة - الاختبارات التي تركز على أجزاء من الرمز البرمجي معزولة بشكل طبيعي وبالتالي لديها تعقيد داخلي خاص بها.
إذا أردت معرفة المزيد عن استراتيجية الاختبار هذه، يمكنك الاطّلاع على المشاركة التي تقارن بين هرم الاختبار وخلية العسل التي كتبها "مارتن فاولر" والمقالة الأصلية من Spotify.
كأس اختبار
يمكنك رؤية تركيز متكرر على اختبارات الدمج. ومع ذلك، هناك نوع آخر صادفته في المقالة السابقة وهو ليس الاختبار النظري ولكنه لا يزال جانبًا مهمًا يجب مراعاته في استراتيجية الاختبار. التحليل الثابت غير موجود في هرم الاختبار وفي معظم عمليات التعديل التي رأيتها حتى الآن. تتوفّر إمكانية تعديل كأس الاختبار التي تأخذ التحليل الثابت في الاعتبار مع الحفاظ على التركيز على اختبارات التكامل. نشأ كأس الاختبار من الاقتباس السابق من قبل غيليرمو راوش وطوره كينت سي. دودز:
كأس الاختبار هي تشبيه يصور دقة الاختبارات بطريقة مختلفة قليلاً. يتكون من أربع طبقات:
- التحليل الثابت: تؤدي هذه الطريقة دورًا حيويًا في هذا التشبيه وتتيح لك اكتشاف الأخطاء الإملائية وأخطاء النمط وغيرها من الأخطاء من خلال اتّباع خطوات تصحيح الأخطاء الموضّحة سابقًا.
- اختبارات الوحدات: فهي تضمن اختبار الوحدة الأصغر حجمًا بشكل مناسب، إلا أن كأس الاختبار لن تؤكد عليها بنفس القدر الذي تركز عليه هرم الاختبار.
- الدمج: هذا هو التركيز الرئيسي لأنه يوازن التكلفة والثقة الأعلى بأفضل طريقة، كما هو الحال مع عمليات التكيّف الأخرى.
- اختبارات واجهة المستخدم: وبعد أن تضم اللعبة اختبارات E2E والاختبارات البصرية، فهي في أعلى كأس الاختبار، على غرار دورها في هرم الاختبار.
لقراءة المزيد عن كأس الاختبار، يمكنك الاطلاع على مشاركة المدونة التي نشرها كينت سي. Dodds حول هذا الموضوع.
بعض الأساليب الأكثر تركيزًا على واجهة المستخدم
هذا جيد وجيد ولكن بغض النظر عن الطريقة التي تستخدم بها استراتيجيتك، مثل "هرم" أو "قرص عسل" أو "ماسة"، لا يزال هناك شيء مفقود. على الرغم من أهمية أتمتة الاختبار، إلا أنّه من المهم تذكُّر أنّ الاختبار اليدوي لا يزال ضروريًا. يُفترض أن يساعد الاختبار الآلي في تقليل المهام الروتينية ويتيح لمهندسي ضمان الجودة التركيز على المجالات المهمة. وبدلاً من استبدال الاختبار اليدوي، يجب أن تكون عملية التشغيل الآلي مكمّلة له. هل مِن طريقة لدمج الاختبار اليدوي مع الأساليب المبرمَجة للحصول على أفضل النتائج؟
اختبار مخروط جليدي واختبار سلطعون
هناك بالفعل تعديلان لهرم الاختبار يركزان بشكل أكبر على طرق الاختبار هذه التي تركز على واجهة المستخدم. فكلاهما يتمتع بثقة عالية، لكنه بطبيعة الحال أكثر تكلفة بسبب بطء تنفيذ الاختبار.
الأول، وهو مخروط ثلج الاختبار، يبدو مثل الهرم في الاتجاه العكسي. دون خطوة الاختبار اليدوي، تُعرف أيضًا باسم بيتزا الاختبار.
يركز مخروط الجليد بشكل أكبر على الاختبار اليدوي أو الاختبار لواجهة المستخدم وتقليل التركيز على اختبار الوحدة. وغالبًا ما تتشكّل في المشاريع التي بدأ فيها المطوّرون العمل ببضع أفكار فقط حول استراتيجية الاختبار. يُعتبر الرمز الجليدي مضادًا للنمط وهو من الصواب، وهو مكلف من حيث الموارد والعمل اليدوي.
يشبه سلطعون الاختبار مخروط الجليد التجريبي، ولكن مع المزيد من التركيز على E2E والاختبار المرئي:
تشتمل استراتيجية الاختبار هذه على جانب آخر: فهي تتحقق من عمل تطبيقك ومظهره بشكل جيد. يسلط السلطعون الاختباري الضوء على أهمية الاختبار المرئي، كما هو موضَّح في المقالة السابقة. ينتقل اختبار الدمج إلى اختبار المكوّنات وواجهة برمجة التطبيقات بشكل أكبر في الخلفية، ويؤدي اختبار الوحدات دورًا ثانويًا هنا. يمكنك الاطّلاع على مزيد من التفاصيل عن استراتيجية الاختبار هذه في هذه المقالة حول نظام السلطعون الاختباري.
وعلى الرغم من كون هاتَين الاستراتيجيتَين الاختباريتَين أكثر تكلفة، إلا أنّ لهما مكانتان في الأداء: على سبيل المثال، في المشاريع الصغيرة التي تكون فيها الحاجة إلى إجراء عدد أقل من الاختبارات، أو التي تحتاج إلى معالجة أقل. في هذه الحالة، قد تكون هناك إفراط في الهندسة البرمجية لاستراتيجية الاختبار الشاملة التي تركّز على اختبار الدمج.
على الرغم من أن هاتين الاستراتيجيتين للاختبار أكثر تكلفة، إلا أنهما مكانهما، على سبيل المثال، في المشروعات الصغيرة التي تتطلب اختبارات أقل ولا تحتاج إلى تناول الكثير من التعقيد. في هذه الحالة، قد تكون استراتيجية الاختبار الشاملة التي تركّز على اختبار التكامل معقّدة بدون داعٍ.
نصيحة عملية: لنضع استراتيجية!
لقد تعرفت الآن على أكثر استراتيجيات الاختبار شيوعًا. لقد بدأت بالكلاسيكي - الهرم الاختباري - وتعرفت على تعديلاته العديدة. أنت الآن بحاجة إلى تقييمها لمنتجك وتحديد الخيار الأفضل لمشروعك. يجب أن تبدأ الإجابة عن هذا السؤال بالخيار المفضّل لدى الجميع "على حسب". هذا لا يجعلها أقل دقة على الرغم من ذلك.
يعتمد اختيار استراتيجية الاختبار الأكثر ملاءمةً من بين الخيارات الموضحة - وحتى الاستراتيجيات المتبقية - على تطبيقك. يجب أن يؤدي ذلك إلى تنقية بنيتك ومتطلباتك، وأخيرًا وليس آخرًا، المستخدمين ومتطلباتهم. كل هذا قد يختلف من تطبيق إلى آخر. فهذا أمر طبيعي تمامًا. تذكر أن أهم هدفك هو خدمة المستخدمين، وليس تعريفًا لكتاب مدرسي.
في أغلب الأحيان، يصعب فصل الاختبارات الواقعية وتعريفها بشكل فردي. إنّ "مارتن فاولر" نفسه يؤكد على الجانب الإيجابي للتعريفات المختلفة، كما هو الحال في اختبارات الوحدات. وكما قال جاستن سيرلز بشكل صحيح في تغريدته:
[...] كتابة اختبارات تعبيرية تضع حدودًا واضحة، وتجري بسرعة وموثوقية، ولا تفشل إلا لأسباب مفيدة.
من تأليف "جاستن سيرلز"
ركز على الاختبارات التي تبلغ عن الأخطاء الفعلية التي قد يواجهها المستخدمون، ولا تصرف انتباهك عن هدفك. يجب أن تهدف الاختبارات إلى إفادة المستخدم، وليس فقط توفير تغطية كاملة لها، أو مناقشة النسبة المئوية لنوع الاختبار الذي يجب كتابته.
ركِّز على الاختبارات التي تبلغ عن أخطاء حقيقية قد يواجهها المستخدمون ولا تشتت انتباهك عن هدفك. يجب تصميم الاختبارات ليستفيد منها المستخدم، وألا يقتصر الأمر على توفير تغطية كاملة بنسبة 100% أو إثارة نقاشات حول النسبة المئوية لنوع الاختبار الذي ينبغي لك كتابته.