متابعة الاختبار والتحكم فيه
متابعة الاختبار (Test Monitoring) والتحكم في الاختبار (Test Control) نشاطان من أنشطة إدارة الاختبار يُبقيان الاختبار على مساره. فالمتابعة هي الجمع المستمر للمعلومات عن جميع أنشطة الاختبار، ومقارنة التقدم الفعلي بخطة الاختبار ومعايير الخروج فيها. والتحكم يستخدم هذه المعلومات لتقرير إجراءات تصحيحية وتطبيقها، ويسميها منهج ISTQB توجيهات التحكم (Control Directives).
مثال: تنص الخطة على تنفيذ 48 من 120 اختباراً بنهاية اليوم الرابع، لكن ما نُفّذ فعلاً 26 فقط، لأن بيئة الاختبار وصلت متأخرة يومين. المتابعة تُظهر هذا الانحراف (Variance)، والتحكم يقرر ما يجب فعله: تشغيل الاختبارات عالية المخاطر أولاً، أو طلب وقت إضافي، أو الاتفاق على استبعاد بعض الاختبارات منخفضة المخاطر. فالمعلومة بلا إجراء لا تغيّر شيئاً، والإجراء بلا معلومة تخمين.
لماذا يهم
كل خطة اختبار تقدير يُوضع قبل أن تتضح الحقائق: فالبيئات تصل متأخرة، والبناء (Build) يتعطل، والعيوب تتجمع في وحدة واحدة. ومن دون متابعة تظهر هذه المشكلات في اليوم الأخير، حين لا يبقى إلا الإطلاق بمخاطر مجهولة أو التأجيل في أسوأ توقيت.
ومع المتابعة والتحكم، عندما يضيق الوقت تُستبعد الاختبارات منخفضة المخاطر بقرار صريح، لا اختبارات الدفع بالمصادفة. ويستطيع المختبِر أن يقول «نحن متأخرون 22 اختباراً، وهذا هو السبب، وهذه هي الخيارات» بدلاً من «أنا مشغول»، وهي رسالة تدفع الفريق إلى إصلاح البيئات المعطلة.
متابعة الاختبار: جمع المعلومات ومقارنتها بالخطة
تحتاج المتابعة إلى خط أساس (Baseline): خطة الاختبار بجدولها الزمني ومعايير الخروج فيها، وجدول تنفيذ الاختبار الذي تعرّفت إليه في درس تهيئة الاختبار. والرقم وحده لا يقول الكثير؛ فعبارة «نُفّذ 26 اختباراً» لا تصبح معلومة إلا بجانب عبارة «المخطط حتى اليوم 48»، أي 54% من الخطة.
في منهج ISTQB CTFL v4.0 تشمل متابعة الاختبار جميع أنشطة الاختبار لا التنفيذ وحده، وتتحقق من مدى استيفاء معايير الخروج، مثل أهداف تغطية المخاطر أو معايير القبول. خذ البيانات من حيث يُسجَّل العمل (أداة إدارة الاختبار، ونظام تتبع العيوب، ونتائج CI)، وثبّت التعريفات حتى تقارن اليوم بالأمس. ومن المعلومات النموذجية:
- تقدم الاختبار: الاختبارات المهيأة، وجاهزية البيئة، والاختبارات المنفذة والناجحة والفاشلة والمحجوبة (Blocked)، أي التي لا يمكن تشغيلها لأن شيئاً تحتاج إليه غير متاح.
- العيوب: المكتشفة والمُصلحة والمفتوحة، حسب الخطورة، وأين تتجمع.
- التغطية: نسبة المتطلبات أو معايير القبول أو مخاطر المنتج التي غطّتها اختبارات نُفّذت فعلاً، وكم نجح من هذه الاختبارات.
- المخاطر والجهد: مخاطر المنتج التي لم تُختبر بعد، والجهد المبذول مقارنةً بالتقدير.
جرّبها: حاسبة النسبة المئوية جرّبها: المتطلبات ← حالات اختبار
التحكم في الاختبار: الإجراءات التصحيحية
يستخدم التحكم في الاختبار معلومات المتابعة لتصحيح مسار الاختبار. وقرار التحكم الجيد يجيب عن ثلاثة أسئلة: ما الانحراف؟ وأي معيار خروج أو هدف من أهداف الاختبار يهدده؟ وما أصغر إجراء يعيد الاختبار إلى مساره؟ والقرار بأنه لا حاجة إلى إجراء هو أيضاً قرار تحكم، إذا اتُّخذ عن قصد.
وليس كل إجراء من صلاحية المختبِر. فإعادة ترتيب الاختبارات أو إضافة جلسة اختبار استكشافي تقع عادةً ضمن صلاحية فريق الاختبار؛ أما تغيير موعد الإصدار أو تقليص النطاق أو قبول خطر متبقٍّ (Residual Risk)، أي الخطر الذي يبقى قائماً، مثلاً لأن بعض الاختبارات لم تُنفَّذ، فيعود إلى أصحاب المصلحة مثل مالك المنتج، ويقدّم لهم المختبِر الحقائق والخيارات. وفي الحالتين يُسجَّل القرار، وتُحدَّث الخطة، وتتحقق جولة المتابعة التالية من نجاحه. ويعامل معيار ISO/IEC/IEEE 29119-2 هذه الحلقة بوصفها إحدى عمليات إدارة الاختبار، إلى جانب تخطيط الاختبار وإتمام الاختبار.
أمثلة على قرارات التحكم
يذكر منهج CTFL v4.0 توجيهات تحكم نموذجية: إعادة ترتيب أولويات الاختبارات عندما يتحول خطر محدَّد إلى مشكلة واقعة (أي حين يقع فعلاً ما كان يُخشى وقوعه)، وإعادة تقييم ما إذا كان عنصر الاختبار (Test Item) لا يزال يستوفي معايير الدخول أو الخروج بعد إعادة العمل (Rework)، وتعديل الجدول عندما تتأخر بيئة الاختبار، وإضافة موارد حيث يلزم. وهي عملياً استجابات لإشارات تتكرر في كل مشروع تقريباً:
- خطر يتحول إلى مشكلة (يغيّر مزوّد الدفع واجهته البرمجية في منتصف الدورة): شغّل اختبارات الدفع وإتمام الشراء أولاً.
- العيوب تتجمع في وحدة واحدة: اختبرها بعمق أكبر، بجلسة اختبار استكشافي مثلاً، واسأل هل للعيوب سبب جذري مشترك.
- البيئة أو بيانات الاختبار متأخرة: عدّل الجدول، وشغّل ما لا يعتمد عليها، وصعّد الأمر مع تسمية مسؤول وموعد.
- إعادة عمل تصل إلى منطقة سبق اختبارها: نفّذ اختبار التأكيد واختبارات الانحدار، ولا تقبل البناء الجديد إلا إذا استوفى معايير الدخول، مثل نجاح اختبار الدخان (Smoke Test).
- بناء يفشل في اختبار الدخان: أوقف التنفيذ عليه بدلاً من تسجيل عشرات حالات الفشل ذات السبب الواحد.
- التوقعات تُظهر أن بعض الاختبارات لن تُنفَّذ: اعرض الخيارات على أصحاب المصلحة، أي مزيداً من الوقت، أو مزيداً من الأشخاص، أو ترك اختبارات منخفضة المخاطر دون تنفيذ مع تسجيل الخطر المتبقي.
جرّبها: مولّد الاختبار المبني على المخاطر جرّبها: مولّد سيناريوهات الانحدار
مثال تطبيقي: اليوم الرابع من دورة اختبار مدتها 10 أيام
متجر إلكتروني يختبر الإصدار 4.2 الذي يضيف قسائم الخصم (Coupons) وصفحة دفع جديدة. الخطة: 120 اختبار نظام في 10 أيام عمل، بمعدل 12 اختباراً يومياً، مجدولة ميزةً بعد ميزة. ومعايير الخروج: نجاح الاختبارات عالية المخاطر كلها وعددها 30، وعدم وجود عيب مفتوح بخطورة حاجب (Blocker) أو حرج (Critical). وقد وصلت بيئة الاختبار متأخرة يومين، في بداية اليوم الثالث.
في نهاية اليوم الرابع يقارن قائد الاختبار البيانات بالخطة. الإجمالي متأخر 22 اختباراً، لكن سطر الاختبارات عالية المخاطر أهم: نُفّذ 8 من 30، و9 محجوبة بسبب توقف بيئة التجربة (Sandbox) الخاصة بالدفع. وخمسة من العيوب السبعة في قسائم الخصم، أحدها حرج. وبمعدل 13 اختباراً يومياً، لن يُنفَّذ نحو 16 اختباراً بحلول اليوم العاشر.
Release 4.2 - system test status, end of day 4 of 10
Planned by day 4 Actual Variance
Tests executed 48 26 -22
High-risk tests executed 20 8 -12
Tests blocked 0 9 +9
Defects found - 7 (5 in coupons)
Open Critical defects 0 1 +1
Pace since the environment arrived (day 3): 13 tests a day
Forecast: 94 tests left, 6 days x 13 = 78, so about 16 will not runتتمة المثال: قرارات التحكم
يتصرف قائد الاختبار فوراً فيما يملكه فريق الاختبار، ويعرض مسألة الجدول الزمني على مالك المنتج في اليوم نفسه:
- إعادة ترتيب الأولويات: تُشغَّل أولاً في اليوم الخامس الاختبارات عالية المخاطر غير المحجوبة وعددها 13، وتنتقل فحوص الشكل منخفضة المخاطر إلى النهاية.
- اختبار أعمق حيث تتجمع العيوب: جلسة اختبار استكشافي محددة المدة على تركيبات قسائم الخصم.
- رفع الحجب: يسمّي فريق DevOps مسؤولاً وموعداً لإعادة بيئة التجربة؛ وإن لم تعد بحلول اليوم السادس، يُبلَّغ أصحاب المصلحة بأن معيار الخروج للاختبارات عالية المخاطر في خطر.
- الاستعداد لإعادة العمل: عند وصول إصلاح العيب الحرج، يُنفَّذ اختبار التأكيد واختبارات الانحدار الخاصة بالقسائم.
- التصعيد: يختار مالك المنتج بين يومين إضافيين، أو مختبِر مُستعار، أو ترك 16 اختباراً منخفض المخاطر دون تنفيذ مع تسجيل الخطر المتبقي.
- التسجيل وإعادة الفحص: تُحدَّث الخطة بكل قرار ومسؤوله وسببه، وتتحقق نقطة المتابعة في اليوم الخامس من نجاح الإجراءات.
- 1الخطةتخطيط الاختبارخط الأساس: 48 من 120 اختباراً بنهاية اليوم الرابع، ومعايير خروج متفق عليها
- 2المتابعةمتابعة الاختباراليوم الرابع: نُفّذ 26، منها 8 من 30 عالية المخاطر، و9 محجوبة، و5 من 7 عيوب في قسائم الخصم
- 3المقارنة بالخطةمتابعة الاختبارتأخر 22 اختباراً؛ وبمعدل 13 يومياً لن يُنفَّذ نحو 16 بحلول اليوم العاشر
فرع: لا انحراف يُذكر: لا إجراء، وتستمر المتابعة
- 4إجراءات فريق الاختبارالتحكم في الاختبارالاختبارات عالية المخاطر أولاً، وجلسة استكشافية على القسائم، ومسؤول وموعد لبيئة التجربة
- 5تصعيد خيار الوقت أو النطاقالتحكم في الاختباريومان إضافيان، أو مختبِر مُستعار، أو ترك 16 اختباراً منخفض المخاطر دون تنفيذقرار أصحاب المصلحة
- 6تحديث الخطة والإبلاغالتحكم في الاختباريُسجَّل كل قرار مع مسؤوله وسببه
عودة إلى الخطوة 2 نقطة المتابعة التالية في اليوم الخامس: هل نجحت الإجراءات؟
أخطاء شائعة
- عرض الأرقام الخام دون الخطة بجانبها: فعبارة «نُفّذ 26» بلا معنى دون «المخطط 48».
- مراقبة الإجمالي وحده، فقد يُخفي أن المنطقة عالية المخاطر متأخرة كثيراً. قسّم الأرقام حسب مستوى الخطر.
- متابعة تنفيذ الاختبار وحده وإهمال تصميم الاختبار والبيئة وبيانات الاختبار، فلا تظهر التأخيرات إلا عند بدء التنفيذ.
- ملاحظة انحراف والأمل في تعويضه بصمت، بدلاً من طرحه ما دامت الخيارات متاحة.
- اتخاذ قرارات أصحاب المصلحة منفرداً: تخطي اختبارات بصمت أو تخفيف معايير الخروج دون اتفاق.
- عدم إغلاق الحلقة: تغيير الخطة دون إبلاغ الفريق، أو عدم التحقق أبداً من نجاح الإجراء.
من منظور ضمان الجودة
في معظم الفرق يقود المتابعة والتحكم من يتولى دور إدارة الاختبار، كقائد الاختبار أو مديره، أو الفريق نفسه في الفرق الرشيقة (Agile) خلال الاجتماعات اليومية ومراجعات السبرنت. وكل مختبِر يغذّي هذين النشاطين: سجّل النتائج في اليوم نفسه، وعلّم الاختبارات المحجوبة مع السبب، واربط العيوب بالاختبارات والمخاطر التي تمسّها. فالبيانات القديمة تجعل المتابعة عمياء.
أبلغ عن الانحراف بوصفه انحرافاً لا نشاطاً: «اختبارات الدفع متأخرة 9 اختبارات لأن بيئة التجربة متوقفة، وإن لم تعد بحلول الخميس فمعيار الخروج للاختبارات عالية المخاطر في خطر». واسأل: أي معيار خروج مهدد؟ ومن يملك القرار؟ وماذا يحدث إن لم نفعل شيئاً؟ ودوّن كل قرار تحكم مع مسؤوله وتاريخه وسببه، فهذه القرارات تصبح الانحرافات التي تشرحها تقارير الاختبار، وهي موضوع الدرس التالي.
تمرين عملي
حلّل حالة دورة انحدار واقترح قرارات التحكم
تختبر إصداراً لتطبيق مصرفي على الهاتف. في نهاية اليوم الثالث من دورة انحدار مدتها خمسة أيام، تعرض أداة إدارة الاختبار البيانات أدناه. الرقم الإجمالي يبدو جيداً؛ فقرّر هل هو كذلك فعلاً.
حدّد الانحرافات ومعايير الخروج المعرّضة للخطر، واقترح إجراءات التحكم، وبيّن من يجب أن يقرر كلاً منها.
Mobile banking app 3.8 - regression cycle, end of day 3 of 5
Plan: 150 tests, 30 a day; the 45 high-risk tests (login, transfers) run first
Exit criteria: all high-risk tests passed; no open Blocker or Critical defect
Planned by day 3 Actual
Tests executed 90 84
High-risk tests executed 45 27
Tests blocked 0 12 (transfers: test accounts locked)
Tests failed - 6 (4 of them on Android 12)
Open defects - Critical 1 (transfer limit not enforced), Major 3
Fix for the Critical defect: promised for day 4- قارن كل صف بالخطة.
- صنّف كل معيار خروج: متحقق، أو على المسار، أو في خطر.
- اكتب إجراءات التحكم، وعلّم كلاً منها «فريق الاختبار» أو «قرار أصحاب المصلحة».
- اكتب ما ستتحقق منه في نهاية اليوم الرابع.
إظهار الإجابة النموذجية
الانحرافات: إجمالاً نُفّذ 84 من 90، أي تأخر 6 فقط. لكن حسب مستوى الخطر نُفّذ 27 من 45 اختباراً عالي المخاطر: تأخر 18، منها 12 محجوبة بسبب حسابات الاختبار المقفلة. أما الستة الباقية فليست محجوبة، ومع ذلك لم تُنفَّذ رغم أن الخطة تقدّم الاختبارات عالية المخاطر: فابحث عن السبب. وأربع من حالات الفشل الست على Android 12، ما يرجّح مشكلة خاصة بالمنصة.
معايير الخروج: «نجاح جميع الاختبارات عالية المخاطر» في خطر؛ و«لا عيب حرجاً مفتوحاً» يبقى في خطر حتى ينجح إصلاح اليوم الرابع في اختبار التأكيد.
فريق الاختبار: فك قفل الحسابات اليوم مع تسمية مسؤول؛ وتشغيل الاختبارات الستة عالية المخاطر غير المحجوبة أولاً؛ واختبار تأكيد الإصلاح وإعادة تشغيل اختبارات انحدار التحويلات؛ وإضافة جلسة اختبار استكشافي قصيرة على Android 12؛ ونقل الاختبارات منخفضة المخاطر إلى النهاية.
أصحاب المصلحة: بمعدل 30 اختباراً يومياً يتسع الوقت لـ 60 من 66 اختباراً متبقياً، قبل إعادة اختبار الإصلاح. ويختار مالك المنتج أو مدير الإصدار بين يوم إضافي على الأكثر، أو ترك 6 اختبارات منخفضة المخاطر على الأقل دون تنفيذ مع تسجيل الخطر المتبقي. وإذا تأخر إصلاح العيب الحرج، فقرار الإطلاق لهم أيضاً.
نقطة متابعة اليوم الرابع: عودة الاختبارات المحجوبة إلى صفر، وتنفيذ الاختبارات عالية المخاطر كلها وعددها 45، وتأكيد إصلاح العيب الحرج، وفرز حالات الفشل على Android 12، ثم تحديث الخطة بما تقرر ومن قرره.
أسئلة شائعة
هل متابعة الاختبار هي نفسها تقارير الاختبار؟
لا، لكنهما مترابطتان. المتابعة تجمع المعلومات وتقارنها بالخطة، والتحكم يتصرف بناءً عليها. أما التقارير فتنقل النتيجة: تقارير تقدم الاختبار أثناء الاختبار، وتقرير إتمام الاختبار في نهايته، وهذا موضوع الدرس التالي.
من المسؤول عن التحكم في الاختبار؟
عادةً الشخص الذي يتولى دور إدارة الاختبار، مثل قائد الاختبار أو مدير الاختبار، وفي الفرق الرشيقة قد يتولى الفريق بعض هذه المهام. ويقدّم المختبِرون البيانات ويقترحون الإجراءات. أما قرارات مواعيد الإصدار والنطاق وقبول الخطر المتبقي فتعود إلى أصحاب المصلحة مثل مالك المنتج.
كم مرة يجب متابعة الاختبار؟
عند نقاط المتابعة التي تحددها خطة الاختبار: كثيراً ما يكون ذلك يومياً أثناء تنفيذ الاختبار (وفي الفرق الرشيقة خلال الاجتماع اليومي)، وفي نهاية كل تكرار (Iteration). وتابع أيضاً عند الأحداث: فالعيب الحرج أو توقف البيئة أو تغيّر النطاق يستدعي فحصاً فورياً بدلاً من الانتظار.
هل متابعة الاختبار هي نفسها مراقبة النظام في بيئة الإنتاج؟
لا. متابعة الاختبار تتتبع تقدم الاختبار ونتائجه مقارنةً بخطة الاختبار. أما مراقبة الإنتاج (Production Monitoring) فترصد نظاماً يعمل فعلاً: التوافر والأخطاء وأزمنة الاستجابة. وقد تفيد بيانات الإنتاج في توجيه الاختبار، لكنهما نشاطان مختلفان.
المراجع
- ISTQB Certified Tester Foundation Level (CTFL) v4.0المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
- ISTQB Glossaryالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.
- ISO/IEC/IEEE 29119-2:2021 — Software and systems engineering — Software testing — Part 2: Test processesنموذج عمليات الاختبار: العمليات المؤسسية وعمليات إدارة الاختبار وعمليات الاختبار الديناميكي، مع أنشطتها ومخرجاتها.
تدرّب بأدوات متقن
حساب النسب المئوية ونسبة التغيّر والزيادة/النقصان وكم تمثّل X من Y بالنسبة المئوية.
حوّل قائمة متطلبات مرقّمة إلى حالات اختبار قابلة للتتبّع مع مصفوفة تربط المتطلبات بالاختبارات.
قيّم الميزات حسب الاحتمالية والأثر، ثم ولّد خطة اختبار مبنية على المخاطر ومرتّبة حسب الأولوية.
ولّد سيناريوهات اختبار الانحدار من وصف التغيير وقائمة الوحدات المتأثرة والمرتبطة.
للتعمّق أكثر
- مقاييس الاختبار التي تقود القراراتما مقاييس الاختبار التي تستحق التتبع — التغطية والتنفيذ والعيوب ومقاييس DORA للتسليم — وكيف تُعرض في التقارير، وكيف تتجنب مقاييس المظهر.
- كيف تكتب خطة اختبار (Test Plan)معايير الدخول والخروج والتعليق والاستئناف
- الاختبار المبني على المخاطرتخفيف المخاطر ومتابعتها أثناء الإصدار
- فرز العيوب (Defect Triage)كيف تدير فرز العيوب: المشاركون، والإيقاع، وقائمة تحقق لكل عيب، ومصفوفة الخطورة × الأولوية، والإسناد، وتحليل السبب الجذري، والأنماط الخاطئة.
تقدّمك في هذا الموضوع
سجّل الدخول لتتابع تقدّمك
علّم الموضوعات مكتملة، وتابع من حيث توقفت، وافتح امتحانات التخصص.