قابلية الاختبار

لماذا يهم

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

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

ما الذي يجعل المتطلب قابلاً للاختبار

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

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

قابلية اختبار النظام: قابلية التحكم وقابلية الملاحظة

المتطلب الواضح لا يمكن اختباره إذا لم يسمح لك النظام بتهيئة الموقف أو برؤية النتيجة. وتصف هذا خاصيتان. قابلية التحكم (Controllability) هي مدى سهولة أن يضع الاختبار النظام في الحالة التي يحتاجها: إنشاء البيانات، وضبط التاريخ، وتشغيل ميزة، وجعل مزوّد الدفع يرفض العملية. وقابلية الملاحظة (Observability) هي مدى سهولة أن يرى الاختبار ما فعله النظام، بما في ذلك النتائج التي لا تصل إلى الشاشة: السجل المخزَّن، والبريد المرسَل، وقيد السجلات، والخطأ بدقته.

وكلتاهما قرار تصميم، وأرخص وقت لطلبهما هو قبل بناء الميزة. ويضع معيار ISO/IEC 25010:2023 قابلية الاختبار ضمن قابلية الصيانة: فالمنتج الذي يصعب اختباره يصعب تغييره بأمان أيضاً. ومن الطلبات المعتادة للمختبِرين:

• طريقة لإنشاء بيانات الاختبار وإعادة ضبطها (سكربت بيانات أولية، أو API، أو شاشة إدارة).
• ساعة أو إعداد لمدة الصلاحية يتحكم فيه الاختبار، لكل ما تنتهي صلاحيته أو يُجدوَل.
• أوضاع تجريبية (Sandbox) أو بدائل اختبار (Test Doubles)، أي بدائل تحاكي الخدمة الحقيقية، للخدمات الخارجية، لتُنتج عند الطلب عملية دفع مرفوضة أو انتهاء مهلة.
• سجلات تحمل معرّف ارتباط (correlation id)، وهو معرّف واحد يربط كل قيود السجل الخاصة بالطلب نفسه، ورموز أخطاء محددة، ورقم إصدار البناء ظاهراً في التطبيق.
• معرّفات ثابتة للأتمتة، مثل السمة data-testid التي يجد بها الاختبار العنصر حتى إن تغيّر نصه أو تخطيطه.
• تأكيد أن منافذ التحكم، مثل إعادة ضبط البيانات أو تغيير الساعة، معطّلة خارج بيئات الاختبار: فنقطة نهاية لإعادة ضبط البيانات يمكن الوصول إليها في بيئة الإنتاج عيبٌ بحد ذاتها.

جرّبها: مولّد استجابات API وهمية

إعادة صياغة متطلب غير قابل للاختبار

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

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

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

مثال تطبيقي: متطلب تجديد الاشتراك

يبيع تطبيق لتعلّم اللغات اشتراكات شهرية. وفي مواصفاته: REQ-21 «ينبغي تذكير المشتركين في وقت مناسب قبل تجديد اشتراكهم. وإذا فشل الدفع، فينبغي إعادة المحاولة بضع مرات قبل أن ينتهي الاشتراك». وفيها قاعدة عمل: BR-9 «الاشتراك الموقوف مؤقتاً لا يُحصَّل منه أي مبلغ».

المراجعة: «في وقت مناسب» و«بضع مرات» غير قابلة للقياس، و«تذكير» و«ينبغي» غير واضحة (بأي قناة، وبأي محتوى، وهل هو إلزامي؟)، والمتطلب REQ-21 يسكت عن الاشتراكات الموقوفة مؤقتاً، فقد يتعارض مع BR-9. يقترح المختبِر الصياغة الواردة أدناه، ويسأل مالك المنتج هل يعني «ينتهي» إلغاء الاشتراك أم إيقافه مؤقتاً، ويدوّن ما يجب أن توفّره بيئة الاختبار:

• ساعة يمكن تقديمها في بيئة الاختبار، لاختبار التذكير (⁦21.1⁩) وإعادة المحاولة (⁦21.3⁩) دون انتظار أسبوع (قابلية التحكم).
• وضع تجريبي (Sandbox) لدى مزوّد الدفع فيه بطاقات اختبار تُرفض عند الطلب، لإنتاج محاولة مرفوضة واحدة أو اثنتين أو ثلاث (قابلية التحكم، ⁦21.3⁩).
• صندوق بريد لالتقاط الرسائل، لقراءة رسالة التذكير ورسالة الإلغاء دون صناديق بريد حقيقية (قابلية الملاحظة، ⁦21.1⁩ و⁦21.3⁩).
• بيانات اختبار فيها اشتراك نشط واشتراك موقوف مؤقتاً، وقائمة محاولات التحصيل في الوضع التجريبي، للتأكد من عدم إجراء محاولة رابعة ومن أن الاشتراك الموقوف لا يُحصَّل منه شيء أبداً (قابلية التحكم والملاحظة، ⁦21.3⁩ و⁦21.4⁩).

REQ-21  التجديد الشهري (صياغة مقترحة؛ القيم يؤكدها مالك المنتج)

21.1  قبل تاريخ التجديد بـ 7 أيام يتلقى المشترك رسالة بريد واحدة تذكر تاريخ التجديد
      والمبلغ وطريقة الإيقاف المؤقت أو الإلغاء.
21.2  في تاريخ التجديد تُحصَّل قيمة الخطة من البطاقة المحفوظة، ويستمر الاشتراك
      شهراً آخر.
21.3  إذا رُفضت عملية التحصيل تُعاد المحاولة بعد يوم واحد وبعد 3 أيام من تاريخ
      التجديد. وإذا رُفضت المحاولات الثلاث يُلغى الاشتراك ويتلقى المشترك رسالة
      بذلك، ولا تُجرى أي محاولة تحصيل أخرى.
21.4  الاشتراك الموقوف مؤقتاً لا يتلقى تذكيراً ولا يُحصَّل منه أي مبلغ (BR-9).
21.5  تظهر كل محاولة تحصيل، مقبولة أو مرفوضة، في «سجل الفواتير» بتاريخها
      ومبلغها ونتيجتها.

جرّبها: المتطلبات ← حالات اختبار جرّبها: مراجع معايير القبول بالذكاء الاصطناعي

أسئلة شائعة

المراجع

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• ISTQB GlossaryISTQBالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
• ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelISO/IEC · 2023نموذج جودة المنتج: الملاءمة الوظيفية وكفاءة الأداء والتوافق وقابلية التفاعل والموثوقية والأمان وقابلية الصيانة والمرونة.