الاختبار المبني على قوائم التحقق
الاختبار المبني على قوائم التحقق (Checklist-Based Testing) تقنية اختبار مبنية على الخبرة: تصمّم الاختبارات وتهيّئها وتنفّذها لتغطي بنود قائمة تحقق. كل بند يسمّي شيئاً يجب فحصه، كمتطلب أو خاصية في الواجهة أو خاصية جودة أو نقطة ضعف معروفة، ويقرّر المختبِر كيف يفحصه. فقد تسأل قائمة تحقق لنماذج الويب: «هل كل حقل إلزامي مُعلَّم قبل أن يرسل المستخدم النموذج؟»، وعند اختبار نموذج تسجيل جديد يحوّل المختبِر هذا البند إلى بضعة فحوص سريعة.
في درس تخمين الأخطاء (Error Guessing) استخدمت خبرتك لتتوقّع إخفاقات محددة وتوجّه إليها هجماتك. أما قائمة التحقق فتحوّل الخبرة إلى شروط اختبار متفق عليها: قائمة مراجَعة ومشتركة بنقاط يغطيها كل مختبِر، أياً كان من يختبر.
لماذا يهم
كثير من التغييرات يُختبر بلا حالات اختبار مفصّلة: فالمواصفات مقتضبة، أو التغيير صغير، أو الوقت ضيق. ومن دون أي بنية تتوقف النتيجة على من يختبر وما يتذكره، فتتسرّب المشكلات المعروفة مرة أخرى. وقائمة التحقق تضع لهذا الاختبار حداً أدنى وقدراً من الاتساق بين المختبِرين.
وهي سجلّ أيضاً: فعبارة «26 بنداً ضمن النطاق: ناجح 24، فشل 2» تخبر الفريق بما غُطّي، وهذا ما لا تفعله عبارة «اختبرت النموذج». ولأن القائمة تنمو من عيوب حقيقية، فهي تنقل دروس الفريق إلى الزملاء الجدد.
قائمة التحقق أساساً للاختبار
يضع منهج ISTQB للمستوى التأسيسي (الإصدار v4.0) الاختبار المبني على قوائم التحقق مع تخمين الأخطاء والاختبار الاستكشافي ضمن التقنيات المبنية على الخبرة (Experience-based techniques). وعندما تختبر بقائمة تحقق فإنها تؤدي دور أساس الاختبار (Test Basis): كل بند شرط اختبار (Test Condition)، واختباراتك موجودة لتغطية هذه الشروط.
ومستوى التفصيل يغيّر سلوك التقنية. فالبند العام مثل «هل رسائل الخطأ مفيدة؟» يترك مجالاً للتقدير: سيفعل مختبِران أشياء مختلفة، وقد يوسّع ذلك التغطية لكنه يجعل الاختبار أقل قابلية للتكرار. أما البند المفصّل فيقترب من حالة اختبار قصيرة. وتُبنى البنود من الخبرة، ومما يهمّ المستخدمين، ومن معرفة كيف تُخفق البرمجيات:
- سجلّ العيوب: مشكلات وصلت إلى المستخدمين أو كان إصلاحها مكلفاً.
- الاستدلالات والمعايير المنشورة: استدلالات قابلية الاستخدام العشرة لياكوب نيلسن (Jakob Nielsen) قائمة تحقق عامة معروفة لقابلية الاستخدام، وكثيراً ما تُبنى قوائم تحقق إمكانية الوصول من معايير النجاح في WCAG 2.2.
- أعراف الفريق: المتصفحات واللغات المدعومة، وصيغ التواريخ والأرقام.
- خصائص الجودة: تذكيرات للاختبار غير الوظيفي مثل الأمان والأداء والتوافق.
كتابة بنود جيدة لقائمة التحقق
يجب أن يستطيع المختبِر فحص كل بند وحده ومباشرةً وتسجيل نتيجة واضحة، ولذلك تصوغ فرق كثيرة البنود أسئلةً تعني فيها «نعم» النجاح. ويذكر المنهج أيضاً ما لا ينتمي إليها: البنود التي يمكن فحصها آلياً، والبنود الأنسب أن تكون معايير دخول أو خروج، والبنود العامة أكثر من اللازم.
- شرط واحد في كل بند. «تظهر الأخطاء وهي مترجمة» بندان؛ فإذا كانت الترجمة وحدها خاطئة لا تستطيع علامة واحدة أن تقول ذلك. ويجوز أن تختبر عدة مدخلات الشرط نفسه، كما في
FRM-07أدناه؛ أما نتيجتان متوقعتان مختلفتان فلا تجتمعان في بند واحد. - قابل للملاحظة ومحدد. البند «تأكّد أن التحقق من مدخلات النموذج يعمل» لا يسمّي نتيجة ظاهرة، أما «بعد إرسالٍ مرفوض، هل يحتفظ النموذج بما كتبه المستخدم، باستثناء كلمة المرور؟» فيسمّيها.
- محدد النطاق. اذكر أين ينطبق البند، مثل كل نموذج، ليعرف المختبِر متى يسجّل «لا ينطبق».
- ليس مما تستطيع أداة فحصه. إذا كان بإمكان أداة Linter (برنامج يفحص الشيفرة وفق قواعد محددة) أو اختبار آلي أن يفحصه، فاتركه للأداة لا للقائمة اليدوية.
- ليس معياراً. «نُشر البناء في بيئة الاختبار» معيار دخول، ومكانه خطة الاختبار.
- قابل للتتبع. أعطِ كل بند معرّفاً، وإذا جاء من عيب فاذكر معرّف العيب، فالبند
FRM-07يشير إلىDEF-1184، ليعرف القرّاء لاحقاً سبب وجوده.
Check that form validation works بعد إعادة كتابته بالمعرّف FRM-07: معرّف ونطاق وإعداد واحد وفحص جوابه نعم أو لا يمكن ملاحظته، والعيب الذي جاء منه البند.بند ضعيف
Check that
أحد البنود المكتوبة بدلاً منه
الجزء 1:FRM-07
- 1المعرّفيتيح للنتائج وتقارير العيوب والنسخ اللاحقة من القائمة أن تشير إلى هذا البند بالذات.غائب في البند الضعيف
- 2النطاقأين ينطبق البند، ليعرف المختبِر متى يسجّل «لا ينطبق». وكلمة
formوحدها لا تحدد أي النماذج. - 3الإعداد: شرط واحدالموقف الوحيد الذي يُنشئه المختبِر. فالتحقق من المدخلات يشمل قواعد كثيرة، وهذا البند يغطي قاعدة واحدة.غائب في البند الضعيف
- 4الفحص: سؤال جوابه نعم أو لاشيء يستطيع المختبِر رؤيته، و«نعم» تعني النجاح. أما
worksفلا تسمّي نتيجة يمكن ملاحظتها. - 5المصدرالعيب الذي جاء منه البند: سبب وجوده، وما يجب النظر فيه قبل إزالته.غائب في البند الضعيف
مثال تطبيقي: اختبار نموذج تسجيل بقائمة تحقق
يحتفظ فريق بقائمة تحقق لنماذج الويب وصلت إلى النسخة 7. ونموذج التسجيل الجديد يطلب الاسم ورقم الجوال والبريد الإلكتروني وكلمة المرور، إضافةً إلى مربع للموافقة على الشروط. ولا تحلّ القائمة محلّ اختبارات الميزة نفسها: فقاعدة كلمة المرور، من 12 إلى 64 حرفاً، ما زالت تحتاج إلى تحليل القيم الحدّية.
على البناء 2.14.0 يحدد المختبِر البنود المنطبقة، ويغطي كلاً منها ببضعة فحوص سريعة، ويسجّل النتيجة:
FRM-02هل كل حقل إلزامي مُعلَّم قبل أن يرسل المستخدم النموذج؟ ناجح.FRM-05هل تقبل حقول الاسم الحروف العربية واللاتينية والمسافات والشرطات؟ فشل: رُفض اسم مكتوب بحروف عربية، والعيبDEF-1302يسجّل المُدخل بالضبط.FRM-07حقل إلزامي تُرك فارغاً ثم «إرسال»: هل يظهر خطأ بجانب هذا الحقل يذكر اسمه؟ ناجح، بعد خمسة فحوص سريعة، واحد لكل حقل إلزامي، ومنها مربع الموافقة على الشروط.FRM-09بعد إرسالٍ مرفوض، هل يبقى كل ما كُتب باستثناء كلمة المرور؟ فشل: عندما كان البريد مسجّلاً من قبل، مسح النموذج رقم الجوال أيضاً؛DEF-1303.FRM-16هل يُفرض حدّ حجم كل ملف مرفوع مع رسالة واضحة؟ لا ينطبق: لا يوجد حقل رفع. وتسجيل «لا ينطبق» يُظهر أن البند نُظر فيه ولم يُنسَ.
جرّبها: مولّد اختبارات التحقق جرّبها: مولّد الاختبارات السلبية
إبقاء قائمة التحقق محدّثة
ينبّه المنهج إلى أن البنود تفقد أثرها تدريجياً لأن المطورين يتعلمون تجنّب الأخطاء التي تستهدفها، وإلى أن العيوب المكتشفة حديثاً عالية الخطورة، أي ذات الأثر الكبير في المنتج أو مستخدميه، قد تستدعي بنوداً جديدة. فحدّث القوائم بانتظام بناءً على تحليل العيوب، مع الحرص على ألا تطول أكثر من اللازم.
تعامل مع القائمة على أنها من مواد الاختبار (Testware) لها مالك ورقم نسخة: اذكر رقم النسخة في كل تقرير اختبار، وقارن النص القديم بالجديد قبل نشر أي تغيير، وراجعها في موعد ثابت، مثل الاجتماع الاستعادي (Retrospective) بعد كل إصدار.
- أضف بنداً عندما يتسرّب إلى بيئة الإنتاج عيب كان البند سيكشفه، أو يُكتشف متأخراً بخطورة عالية، مثل حرج (Critical) أو رئيسي (Major)؛ وسجّل معرّف ذلك العيب مصدراً للبند.
- أعد كتابة أي بند يفهمه مختبِران فهمين مختلفين، فهذا عيب في القائمة نفسها.
- أزل البنود التي صار فحص آلي يغطيها أو التي لم تفشل منذ مدة طويلة، بعد أن تسأل: هل تعلّم الفريق الدرس، أم أن البند لا يُفحص فعلاً؟
- عندما لا يتسع الوقت المتاح لتمريرة كاملة، قسّم القائمة حسب المجال، مثل النماذج والقوائم والمدفوعات، بدلاً من أن يمرّ عليها المختبِرون على عجل.
أخطاء شائعة
- بنود عامة جداً، مثل «افحص الواجهة»، فيفعل مختبِران أشياء مختلفة ولا يستطيع أي منهما أن يقول هل نجح البند.
- عدة شروط في بند واحد، فتُسجَّل النتيجة «ناجح» أو «فشل» دون بيان الجزء الذي فشل.
- وضع علامة على البنود دون تدوين البناء والبيانات وما فُحص فعلاً.
- معاملة القائمة على أنها الاختبار كله، مع أن قواعد الميزة نفسها ما زالت تحتاج إلى تقسيم التكافؤ وتحليل القيم الحدّية.
- ترك القائمة تنمو فقط، بلا مالك ولا رقم نسخة، وفيها بنود لا يستطيع أحد شرحها.
من منظور ضمان الجودة
تثبت قوائم التحقق قيمتها حيث تُختبر أشياء متشابهة كثيراً: كل نموذج جديد، وكل إصدار مرشّح، وكل مراجعة لإمكانية الوصول. وعادةً يملك القائمة مختبِر أول أو قائد الاختبار، ويضيف المطورون والمصممون بنوداً. اتفقوا على قيم النتائج: ناجح، فشل، لا ينطبق، لم يُنفَّذ، وسجّلوا البناء ورقم نسخة القائمة ومعرّف العيب لكل بند فشل.
عندما تستخدم قائمة كتبها غيرك، اسأل: من أين جاء كل بند، وهل ينطبق على هذه الميزة، وما الذي يُعدّ نجاحاً؟ وعندما تجد عيباً كانت القائمة ستكشفه، اقترح بنداً جديداً في تقرير العيب أو في الاجتماع الاستعادي.
تمرين عملي
أعد كتابة قائمة تحقق ضعيفة واختبر بها
كتب زميل قائمة التحقق أدناه لصفحة البحث في متجر كتب إلكتروني. أعد كتابتها بحيث يكون كل بند محدداً وقابلاً للملاحظة ويمكن فحصه وحده، واحذف ما لا ينتمي إليها، وأعطِ كل بند معرّفاً ونطاقاً.
ثم صِف الفحوص المحددة التي ستجريها لبندين من بنودك.
قائمة تحقق صفحة البحث
1. البحث يعمل.
2. النتائج صحيحة وسريعة ومرتبة كما يجب.
3. افحص البحث بالأحرف الخاصة.
4. اختبارات الوحدة لخدمة البحث ناجحة.
5. لا أخطاء في وحدة التحكم (اختبارات المتصفح الآلية في CI تفشل عندها أصلاً).
6. الواجهة تبدو جيدة.- قرّر لكل بند: إعادة كتابة أو تقسيم أو حذف، ولماذا.
- صُغ البنود المتبقية أسئلةً جوابها نعم أو لا عن شيء يمكن ملاحظته.
- أضف معرّفاً ونطاقاً لكل بند.
- لبندين منها، اكتب الفحوص وما ستسجّله.
إظهار الإجابة النموذجية
البند 1 عام جداً: أعد كتابته فحصاً قابلاً للملاحظة (SRCH-01). وقسّم البند 2: «صحيحة» يغطيها SRCH-01، و«مرتبة» تصبح SRCH-02، و«سريعة» تحتاج إلى حدّ متفق عليه أو تُترك لاختبار الأداء. والبند 3 لا يسمّي الأحرف ولا النتيجة المتوقعة: أعد كتابته (SRCH-03). واحذف البند 4 (معيار دخول، لا شرط اختبار) والبند 5 (فحص آلي يغطيه). والبند 6 مسألة ذوق: ضع مكانه بنوداً قابلة للملاحظة مثل SRCH-04.
إعادة كتابة ممكنة: SRCH-01 [مربع البحث] هل يُظهر البحث بعنوان مطابق من الكتالوج ذلك الكتاب في الصفحة الأولى من النتائج؟ SRCH-02 [النتائج] عند اختيار «السعر: من الأقل إلى الأعلى»، هل كل سعر أقل من التالي أو يساويه، عبر الصفحات أيضاً؟ SRCH-03 [مربع البحث] هل تعيد عبارات فيها فاصلة عليا أو شرطة أو حروف عربية كتباً مطابقة دون صفحة خطأ؟ SRCH-04 [النتائج] عند تكبير المتصفح إلى 200%، هل تبقى كل العناوين والأسعار ظاهرة كاملة؟
فحوص SRCH-02: في بحث له 25 نتيجة على الأقل، اختر «السعر: من الأقل إلى الأعلى»، وقارن الأسعار نزولاً في الصفحة 1 ثم في الصفحة 2، وسجّل «ناجح» أو «فشل» مع رقم البناء. وفحوص SRCH-03: ابحث عن O'Brien ثم e-book ثم رواية، ودوّن العبارة بالضبط مع أي «فشل».
أسئلة شائعة
ما الفرق بين الاختبار المبني على قوائم التحقق وتخمين الأخطاء؟
يبدأ تخمين الأخطاء من توقّع: كل اختبار يستهدف خطأً أو عيباً أو إخفاقاً محدداً تتوقعه، وكثيراً ما يُؤخذ من قائمة أعطال. أما الاختبار المبني على قوائم التحقق فيعمل من قائمة مكتوبة ومشتركة بشروط الاختبار، قد تشمل متطلبات وخصائص الواجهة وخصائص الجودة إلى جانب نقاط الضعف المعروفة؛ والبند يقول ما يجب فحصه، لا أي إخفاق تتوقعه. وكثيراً ما تتحول بنود قائمة الأعطال التي تظل تكشف عيوباً إلى بنود في قائمة التحقق.
هل قائمة التحقق هي نفسها مجموعة حالات اختبار؟
لا. حالة الاختبار تذكر الشروط المسبقة والمدخلات والخطوات والنتيجة المتوقعة. أما بند قائمة التحقق فيسمّي شرطاً يجب فحصه ويترك الخطوات الدقيقة للمختبِر. لذا تُكتب القوائم وتُصان أسرع، وتسمح بتنوع أكبر بين المختبِرين، وقد يوسّع ذلك التغطية لكنه يقلل قابلية التكرار. وحيث يجب تكرار الفحص بالضبط، كما في قاعدة عالية المخاطر، اكتب حالة اختبار.
ما الطول المناسب لقائمة التحقق؟
طويلة بما يكفي لتغطية المخاطر التي وُضعت لها، وقصيرة بما يكفي لتُستخدم كاملةً في الوقت المتاح. ولا يحدد أي معيار عدداً. وإذا بدأ المختبِرون يمرّون على البنود على عجل أو يتخطّونها، فقسّم القائمة حسب المجال أو أزل البنود التي لم تعد تكشف مشكلات.
هل أبدأ من قائمة تحقق ولّدتها أداة ذكاء اصطناعي؟
مسودةً، نعم: تقترح أداة AI QA Checklist Generator بنوداً لأي ميزة. راجع كل بند وفق قواعد هذا الدرس، أي شرط واحد وقابل للملاحظة ومحدد النطاق وليس مما تستطيع أداة فحصه، واحذف البنود العامة قبل أن تختبر بها. فقيمة القائمة تأتي من هذه المراجعة ومن سجلّ عيوب فريقك.
المراجع
- ISTQB Certified Tester Foundation Level (CTFL) v4.0المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
- ISTQB Glossaryالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
- 10 Usability Heuristics for User Interface Design (Jakob Nielsen)قواعد Jakob Nielsen العامة العشر لتصميم الواجهات — مثل وضوح حالة النظام ومنع الأخطاء — التي وُضعت أصلاً للتقييم الاستدلالي.
- Web Content Accessibility Guidelines (WCAG) 2.2توصية W3C التي تحدد معايير النجاح القابلة للاختبار لإتاحة محتوى الويب، مرتّبةً تحت أربعة مبادئ وثلاثة مستويات مطابقة (A وAA وAAA).
تدرّب بأدوات متقن
ولّد حالات اختبار للتحقق من حقول النماذج: الإلزامية والصيغة والطول والنطاق والنمط والقواعد المشتركة بين الحقول.
ولّد حالات اختبار سلبية لحقول النماذج وواجهات API: قيم فارغة وnull ونوع خاطئ وطول زائد وحقن وصيغة غير صالحة.
قارن نصّين سطراً بسطر أو كلمةً بكلمة مع إبراز الاختلافات.
ولّد قائمة تحقق QA مخصّصة (وظيفية وواجهة مستخدم وAPI وأمان وأداء وإمكانية وصول وإصدار) لأي ميزة باستخدام الذكاء الاصطناعي من متقن.
للتعمّق أكثر
تقدّمك في هذا الموضوع
سجّل الدخول لتتابع تقدّمك
علّم الموضوعات مكتملة، وتابع من حيث توقفت، وافتح امتحانات التخصص.