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