معايير الدخول والخروج

لماذا يهم

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

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

معايير الدخول: هل النشاط جاهز للبدء؟

يجمع منهج ISTQB معايير الدخول المعتادة في ثلاثة أنواع: توفّر الموارد (الأشخاص والأدوات والبيئات وبيانات الاختبار والميزانية والوقت)، وتوفّر مواد الاختبار (Testware) مثل أساس الاختبار والمتطلبات القابلة للاختبار وقصص المستخدم وحالات الاختبار، ومستوى الجودة الأولي لموضوع الاختبار، كنجاح اختبارات الدخان. وينبغي أن تُحدَّد لكل مستوى اختبار على حدة، وتختلف باختلاف أهداف الاختبار فيه، فمعايير الدخول إلى اختبار المكوّنات ليست معايير الدخول إلى اختبار القبول.

وإذا لم يتحقق أحد معايير الدخول، يقرّر الفريق ما يفعله: إما الانتظار، أو البدء بالأجزاء غير المتأثرة فقط (اختبارات الواجهة البرمجية بينما بناء واجهة المستخدم معطّل)، أو البدء رغم ذلك مع تسجيل الخطر وقبوله ممن اتفقوا على المعايير.

• البيئة: البناء المرشّح للإصدار (Release candidate) منشور في بيئة الاختبار، وكل فحوص جاهزية الخدمات (Health checks) ناجحة.
• الجودة الأولية: حزمة اختبارات الدخان تنجح في ⁦25⁩ من ⁦25⁩ اختباراً على هذا البناء.
• مواد الاختبار والبيانات: حالات الاختبار لكل المتطلبات عالية الخطر مراجَعة من زميل، و⁦50⁩ حساباً تجريبياً للعملاء محمَّلة، منها حسابات بأسماء عربية وأخرى ببطاقات منتهية الصلاحية.

جرّبها: فاحص صحة API

معايير الخروج: هل اكتمل النشاط؟

يصف المنهج نوعين من معايير الخروج. مقاييس الشمول (Measures of thoroughness) تقول كم أُنجز: التغطية المتحققة، والعيوب غير المحلولة، وكثافة العيوب، وحالات الاختبار الفاشلة. والمعايير الثنائية بنعم أو لا (Binary yes/no criteria) تقول هل أُنجز أمر ما: تنفيذ الاختبارات المخططة، وإجراء الاختبار الساكن، والإبلاغ عن كل عيب اكتُشف، وأتمتة اختبارات الانحدار. وقد سمّت الطبعة الأولى من CTFL v4.0 هذا النوع الثاني «معايير الإكمال» (Completion criteria)، ثم غيّرت النسخة v4.0.1 اسمه حتى لا يُخلط بمعايير الخروج كلها.

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

جرّبها: المتطلبات ← حالات اختبار جرّبها: حاسبة النسبة المئوية

معايير التعليق والاستئناف

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

• علّق الاختبار حين تفشل حزمة الدخان على بناء جديد؛ واستأنفه حين ينجح فيها بناء مُصحَّح.
• علّق الاختبار حين تتعطل بيئة الاختبار أو بيئة تجريبية مطلوبة (Sandbox) أكثر من ⁦4⁩ ساعات عمل؛ واستأنفه حين تُستعاد وتنجح فحوص جاهزيتها.
• علّق الاختبار حين يحجب عيب واحد أكثر من ⁦30%⁩ من حالات الاختبار المتبقية؛ واستأنفه حين ينجح إصلاحه في اختبار التأكيد.
• عند الاستئناف أعد تنفيذ الاختبارات التي كانت جارية، وسجّل الوقت الضائع في تقرير تقدم الاختبار التالي.

معايير يحكم عليها شخصان بالطريقة نفسها

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

• «البناء مستقر» يصبح «حزمة الدخان تنجح في ⁦25⁩ من ⁦25⁩ اختباراً على البناء قيد الاختبار».
• «الاختبار مكتمل» يصبح «كل حالات الاختبار عالية الخطر ناجحة، ونُفّذ ⁦95%⁩ على الأقل من حالات الاختبار المخططة».
• «لا أخطاء كبيرة» يصبح «لا عيوب حاجبة أو حرجة مفتوحة، ولكل عيب رئيسي (Major) مفتوح حل بديل مقبول».
• «تغطية جيدة» يصبح «لكل متطلب ضمن النطاق حالة اختبار ناجحة واحدة على الأقل».
• «الأداء مقبول» يصبح «مع ⁦200⁩ مستخدم متزامن، تستجيب ⁦95%⁩ من عمليات البحث خلال ⁦2.0⁩ ثانية أو أقل (p95)».

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

مثال تطبيقي: فحص معايير الخروج قبل الإصدار

يضيف الإصدار ⁦3.5⁩ من تطبيق لتوصيل الطعام الطلبات المجدولة. ولخطة اختبار النظام ستة معايير خروج: تنفيذ كل حالات الاختبار عالية الخطر ونجاحها، وتنفيذ ⁦95%⁩ على الأقل من حالات الاختبار المخططة البالغة ⁦150⁩، وعدم وجود عيب حاجب أو حرج مفتوح، و⁦3⁩ عيوب رئيسية مفتوحة كحد أقصى، ونجاح حزمة الانحدار على البناء المرشّح للإصدار، وتغطية كل متطلب ضمن النطاق باختبار ناجح. وفي نهاية اليوم ⁦9⁩ يفحص قائد الاختبار كل معيار مقابل بيانات أداة إدارة الاختبار ومتتبّع العيوب.

• متحقق: نجحت ⁦38⁩ من ⁦38⁩ حالة عالية الخطر، والعيوب الرئيسية المفتوحة ⁦2⁩، ونجحت حزمة الانحدار في ⁦212⁩ من ⁦212⁩، ولكل متطلب من المتطلبات الـ⁦27⁩ اختبار ناجح.
• غير متحقق: تنفيذ ⁦141⁩ من ⁦150⁩ يساوي ⁦94%⁩. والحالات التسع المتبقية فحوص منخفضة الخطر لسجل الطلبات، فإما أن ينفّذها الفريق في يوم إضافي، أو يقبل مالك المنتج الفجوة كتابياً.
• غير متحقق: كشفت جلسة اختبار استكشافي في اليوم ⁦8⁩ أن تغيير الفترة الزمنية لطلب مجدول يخصم المبلغ من البطاقة مرتين. ولن يقبل مالك المنتج عيباً حرجاً يخصم من العملاء مرتين، فالإصلاح يأتي أولاً.
• ينتج عن الإصلاح بناء مرشّح جديد للإصدار. فينفّذ المختبِر اختبار التأكيد للعيب، ويعيد تشغيل حزمة الانحدار، ويعيد فحص المعايير الستة على هذا البناء، ويسجّل النتيجة في تقرير إتمام الاختبار.

Release 3.5, system testing: exit criteria at the end of day 9

Criterion                                   Target      Actual           Met
High-risk test cases executed and passed    100%        38/38 (100%)     yes
Planned test cases executed                 >= 95%      141/150 (94%)    no
Open Blocker or Critical defects            0           1 Critical       no
Open Major defects                          <= 3        2                yes
Regression suite on the release candidate   all pass    212/212          yes
In-scope requirements with a passed test    100%        27/27            yes

أسئلة شائعة

المراجع

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• ISTQB GlossaryISTQBالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
• ISO/IEC/IEEE 29119-3:2021 — Software and systems engineering — Software testing — Part 3: Test documentationISO/IEC/IEEE · 2021نماذج ومحتوى وثائق الاختبار — سياسة الاختبار واستراتيجيته وخطته وتقارير الحالة والإنجاز وتقارير الحوادث.