مبادئ الاختبار السبعة

لماذا يهم

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

وبالنسبة إليك مختبِراً، فالمبادئ هي الحجج التي تقف خلف قراراتك: لماذا تنال وحدة الدفع اختباراً أكثر من صفحة الإعدادات، ولماذا تريد رؤية القصة قبل بنائها، ولماذا لا تكون عبارة «نجحت كل الاختبارات» هي التقرير كله. والقرار يُقبل بسهولة أكبر حين تستطيع تسمية سببه.

المبادئ السبعة في منهج ISTQB CTFL v4.0

يسرد القسم ⁦1.3⁩ من منهج ISTQB للمستوى التأسيسي (الإصدار ⁦4.0⁩) هذه المبادئ السبعة بهذه الأسماء. كل مبدأ خلاصة خبرة طويلة في مشاريع كثيرة، وكل مبدأ يغيّر شيئاً تفعله.

• المبدأ الأول، «الاختبار يُظهر وجود العيوب لا غيابها» (Testing shows the presence, not the absence of defects): يستطيع الاختبار أن يُظهر وجود عيوب، لكنه لا يستطيع إثبات خلوّ البرنامج منها. وهو يقلّل احتمال بقاء عيوب غير مكتشفة.
• المبدأ الثاني، «الاختبار الشامل مستحيل» (Exhaustive testing is impossible): اختبار كل شيء غير ممكن إلا في الحالات البسيطة جداً، لذا يُركَّز الجهد بتقنيات الاختبار وترتيب أولويات حالات الاختبار والاختبار المبني على المخاطر.
• المبدأ الثالث، «الاختبار المبكر يوفّر الوقت والمال» (Early testing saves time and money): العيب الذي يُزال مبكراً لا يسبّب عيوباً أخرى في نواتج العمل المبنية عليه، وتقلّ الإخفاقات التي تقع لاحقاً في دورة الحياة.
• المبدأ الرابع، «العيوب تتجمّع» (Defects cluster together): عدد قليل من المكوّنات يحتوي عادةً معظم العيوب المكتشفة، أو يسبّب معظم الإخفاقات أثناء التشغيل، وهذا مثال على مبدأ باريتو (Pareto principle).
• المبدأ الخامس، «الاختبارات تَبلى» (Tests wear out)، واسمه الأقدم مفارقة المبيد الحشري (Pesticide paradox): الاختبارات التي تتكرر مرات كثيرة دون تغيير تكشف عيوباً جديدة أقل فأقل.
• المبدأ السادس، «الاختبار يعتمد على السياق» (Testing is context dependent): لا يوجد نهج واحد يناسب كل منتج، فالاختبار يُجرى بطرق مختلفة في سياقات مختلفة.
• المبدأ السابع، «مغالطة غياب العيوب» (Absence-of-defects fallacy)، واسمها الأقدم مغالطة غياب الأخطاء (Absence-of-errors fallacy): التحقق (Verification) وحده لا يجعل النظام ناجحاً، إذ يجب أن يلبي أيضاً احتياجات مستخدميه، لذا يلزم التحقق من الصلاحية (Validation) أيضاً.

ما يستطيع الاختبار ادّعاءه وما لا يستطيع: المبادئ الأول والثاني والسابع

المبدأ الأول يغيّر طريقة إبلاغك. ينجح تطبيق مصرفي في اختبارات الانحدار كلها وعددها ⁦250⁩ اختباراً، وبعد أسبوع من الإصدار يكتشف العملاء أن التحويلات الدورية المجدولة يوم ⁦31⁩ تُتخطّى في الأشهر التي تقل أيامها عن ⁦31⁩ يوماً. لم يستخدم أي اختبار ذلك التاريخ. وكما رأيت في درس أهمية اختبار البرمجيات، فإن التنفيذ الناجح دليل على ما اختُبر، ولا يقول شيئاً عمّا لم يُختبر؛ لذا أبلِغ عن النطاق والنتائج وما لم يُختبر والمخاطر المتبقية، ولا تقل أبداً إن البرنامج «خالٍ من الأخطاء».

المبدأ الثاني يغيّر طريقة اختيارك للاختبارات. نموذج البحث عن فندق أدناه فيه خمسة حقول وأكثر من ⁦17⁩ مليون تركيبة صالحة، قبل احتساب القيم غير الصالحة والمتصفحات والأجهزة. لذا تختار الاختبارات بتقنيات تصميم الاختبار التي ستتعلّمها لاحقاً في المسار: أقسام التكافؤ والقيم الحدّية لكل حقل، وتركيبات الاختبار الزوجي (Pairwise) بين الحقول، وأكبر عمق حيث يكون الإخفاق أشدّ ضرراً.

المبدأ السابع يغيّر ما تفحصه إلى جانب المواصفات. بوابة تسجيل المقررات في جامعة تحقق كل القواعد المحددة وعددها ⁦40⁩ قاعدة، وقد أُصلح كل عيب اكتُشف، ومع ذلك يواصل الطلاب التسجيل في مقررات تتعارض أوقات محاضراتها، لأن البوابة لا تعرض جدولاً زمنياً أبداً. وكما في درس التحقق والتحقق من الصلاحية: راقب مستخدمين حقيقيين وهم يؤدّون المهمة الرئيسية، وشارك في اختبار القبول، وأبلِغ عن مثل هذه الفجوات حتى إن لم يُخالَف أي متطلب.

Hotel search: every valid combination

city          50
check-in     365   (dates up to one year ahead)
nights        30   (1..30)
guests         8   (1..8)
room type      4
------------------------------------------------
50 x 365 x 30 x 8 x 4 = 17,520,000 combinations
At one test per second: about 203 days, nonstop

جرّبها: مولّد الاختبار الزوجي (Pairwise)

أين ومتى تضع الجهد: المبادئ من الثالث إلى السادس

المبدأ الثالث يغيّر توقيت بدايتك. تتبّع درس أهمية اختبار البرمجيات عيباً واحداً في متطلب عبر ثلاث لحظات، وكانت كلفته تزداد في كل لحظة لاحقة، والأمر نفسه ينطبق على كل قصة. تقول قصة مستخدم: «يمكن للمستخدم رفع صورة شخصية حتى ⁦5⁩ ميغابايت». في جلسة التنقيح (Refinement) تسأل: ما الصيغ المسموح بها؟ وهل تعني ⁦5⁩ ميغابايت ⁦5,000,000⁩ بايت أم ⁦5,242,880⁩ بايت؟ وماذا يرى المستخدم إذا كان الملف أكبر من الحد؟ ثلاث إجابات الآن قد تمنع ثلاثة عيوب لاحقاً. راجع القصص ومعايير القبول والتصاميم فور وجودها، ونفّذ الاختبارات فور وجود ما يمكن تشغيله.

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

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

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

جرّبها: مولّد معايير القبول جرّبها: مولّد الاختبار المبني على المخاطر جرّبها: مولّد سيناريوهات الانحدار

مثال تطبيقي: «هل تؤكد لنا عدم وجود أخطاء قبل الخميس؟»

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

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

أسئلة شائعة

المراجع

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• ISTQB GlossaryISTQBالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
• Lessons Learned in Software Testing: A Context-Driven Approach (Cem Kaner, James Bach, Bret Pettichord)Wiley · 2001دروس عملية في الإبلاغ عن الأخطاء وتصميم الاختبارات والأتمتة وإدارة الاختبار — مدرسة الاختبار المدفوع بالسياق.