أهمية اختبار البرمجيات

لماذا يهم

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

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

ماذا يمكن أن يكلّف الإخفاق

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

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

الاختبار يقلّل المخاطر ويدعم القرارات

الخطر (Risk) حدث قد يقع فيُحدث ضرراً، ويصفه ISTQB بعاملين: الاحتمالية (Likelihood) والتأثير (Impact). ويخفّض الاختبار مستوى المخاطر بطريقتين: فهو يكشف عيوباً يصلحها المطورون بعد ذلك، وحين تنجح اختبارات منطقة عالية المخاطر يصبح لدى الفريق دليل، لا مجرد أمل، على أنها تعمل في الظروف التي اختُبرت فيها.

والاختبار ينتج معلومات أيضاً، وتزويد أصحاب المصلحة بما يحتاجونه لاتخاذ قرارات مستنيرة هدف من أهداف الاختبار في منهج ISTQB. فمالك المنتج الذي يقرر هل يُصدر النسخة يوم الخميس يحتاج إلى صورة كالتي أدناه. والقرار قراره؛ أما المختبِر فيجعل الصورة دقيقة وصريحة في بيان حدودها.

• ما اختُبر: إتمام الشراء والدفع بالبطاقة والاسترداد؛ ⁦48⁩ اختباراً: نجح ⁦46⁩، وفشل واحد، ولم يُنفَّذ واحد.
• المفتوح: عيب واحد مستوى خطورته «رئيسي» (Major)؛ رسالة الاسترداد بالبريد الإلكتروني تعرض مبلغاً خاطئاً، مع أن الاسترداد نفسه صحيح.
• ما لم يُختبر: الدفع بالمحفظة الرقمية على iOS، لعدم توفر جهاز اختبار.
• الخيارات: الإصدار مع إبلاغ فريق الدعم وإصلاح الرسالة في الإصدار ⁦4.2.1⁩، أو التأجيل يوماً واحداً.

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

ما يستطيع الاختبار إظهاره وما لا يستطيع

أول مبادئ الاختبار السبعة في منهج ISTQB أن الاختبار يُظهر وجود العيوب لا غيابها. فالاختبار الفاشل، بعد أن تتحقق من سلامة الاختبار نفسه وبيئته، يُظهر وجود عيب، أما الاختبار الناجح فيُظهر فقط أن هذا الاختبار، بهذه البيانات وفي هذه البيئة، لم يكشف عيباً. والاختبار يقلّل احتمال بقاء عيوب غير مكتشفة لكنه لا يُثبت صحة البرنامج، والاختبار الشامل لكل الحالات (Exhaustive testing) مستحيل: فحتى النموذج الصغير الذي يضم بضعة حقول نصية له من تركيبات المدخلات أكثر مما يستطيع أحد تنفيذه.

ويسهم الاختبار في الجودة دون أن يصنعها وحده: فالعيوب التي يكشفها تُزال بالتنقيح (Debugging) والإصلاح. وكما رأيت في درس التحقق والتحقق من الصلاحية، قد يجتاز البرنامج كل اختبار مقابل مواصفاته ومع ذلك لا يلبي احتياجات المستخدمين؛ ويسمي ISTQB ذلك مغالطة غياب العيوب (Absence-of-defects fallacy).

لذلك فعبارة «نجحت كل الاختبارات» تعني أن الاختبارات المخطط لها لم تكشف إخفاقاً، لا أنه لم يبقَ أي عيب ولا أن المناطق غير المختبَرة تعمل. والتقرير الجيد يذكر ما لم يُختبر والمخاطر الباقية، وتُسمى المخاطر المتبقية (Residual risk).

مثال تطبيقي: عيب واحد يُكتشف في ثلاث لحظات

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

المتطلب: «يمكن للعملاء إلغاء الطلب خلال ⁦24⁩ ساعة واسترداد المبلغ كاملاً». لا يحدد المتطلب متى تبدأ الساعات الـ⁦24⁩، ولا هل يشمل «كاملاً» رسوم التوصيل، فيفترض المطور أنها تبدأ لحظة تقديم الطلب. والاختبارات المكتوبة على هذا الافتراض ستنجح كلها. تتبّع هذا العيب في ثلاث لحظات:

• اكتُشف في مراجعة المتطلبات: يسأل المختبِر «⁦24⁩ ساعة بدءاً من متى؟ وهل تُسترد رسوم التوصيل؟». فيجيب مالك المنتج (من تأكيد الدفع، والرسوم فقط إن لم يُشحن الطلب بعد)، وتُعاد صياغة الجملة. الكلفة: محادثة وتعديل نص، لأن شيئاً لم يُبنَ على العيب بعد.
• اكتُشف في اختبار النظام (System testing)، وفيه يفحص المختبِرون التطبيق كاملاً بعد تجميع أجزائه في بيئة اختبار: اختبار لطلب دُفع بتحويل بنكي وأُكِّد في اليوم التالي يُظهر أنه لا يمكن إلغاؤه حتى بعد التأكيد مباشرة. الكلفة: تقرير عيب، وتعديل في الكود، واختبار تأكيد، واختبارات انحدار، وربما تأخير الإصدار.
• اكتُشف في الإنتاج: العملاء الذين دفعوا بالتحويل لا يستطيعون الإلغاء فيشتكون، بينما يسترد آخرون رسوم توصيل لم تقصدها الشركة قط. الكلفة: كل ما سبق، إضافة إلى حادثة وإصلاح عاجل (Hotfix) ومبالغ مستردة يدوياً وتصحيح بيانات الطلبات وثقة مفقودة.

جرّبها: مولّد معايير القبول جرّبها: كاشف غموض المتطلبات بالذكاء الاصطناعي

أسئلة شائعة

المراجع

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• ISTQB GlossaryISTQBالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
• ISO/IEC/IEEE 29119-1:2022 — Software and systems engineering — Software testing — Part 1: General conceptsISO/IEC/IEEE · 2022المعيار الدولي لاختبار البرمجيات: المفاهيم والعمليات والتوثيق والتقنيات.
• Personal Data Protection Law (English translation)الهيئة السعودية للبيانات والذكاء الاصطناعي (سدايا) · 2023النظام السعودي لحماية البيانات الشخصية — ولماذا ينبغي أن تستخدم بيئات الاختبار بيانات اصطناعية بدلاً من نسخ سجلات العملاء الحقيقية.