الوحدة 4 · عملية الاختبار (STLC)

إتمام الاختبار وإغلاقه

بقلم فريق ضمان الجودة في متقن سوفت · · 17 دقيقة · مبتدئ

إتمام الاختبار (Test Completion) هو النشاط الأخير في عملية الاختبار. يحدث عند معلَم من معالم المشروع، كإصدار أو نهاية تكرار أو انتهاء مستوى اختبار، ويحوّل تنفيذ الاختبار إلى نتائج يستطيع الفريق استخدامها لاحقاً: قرار لكل عيب مفتوح، ومواد اختبار (Testware) مؤرشفة أو مسلَّمة، وبيئة اختبار متروكة في حالة متفق عليها، ودروس مستفادة، وتقرير إتمام الاختبار. تسميه المناهج الأقدم وكثير من الفرق إغلاق الاختبار (Test Closure) أو إغلاق دورة الاختبار، أما منهج ISTQB CTFL الإصدار ⁦4.0⁩ فيسميه إتمام الاختبار.

مثال: يطلق فريق صفحة الدفع الإصدار ⁦3.4⁩ يوم الإثنين. وفي يوم الثلاثاء ينقل المختبِر العيبين غير المُصلَحين إلى قائمة مهام المنتج (Product Backlog)، ويضيف اختبارات API الجديدة إلى حزمة الانحدار، ويحذف حسابات المشرفين المؤقتة من بيئة Staging، ويدير نقاشاً قصيراً حول الدروس المستفادة، ويرسل تقرير الإتمام إلى مالك المنتج وقائد التطوير وقائد الدعم.

لماذا يهم

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

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

متى يحدث إتمام الاختبار

يضع منهج CTFL الإصدار ⁦4.0⁩ إتمام الاختبار عند معالم المشروع: إصدار، أو نهاية تكرار، أو انتهاء مستوى اختبار مثل اختبار النظام. وعادةً تُجري الفرق الرشيقة (Agile) إتماماً خفيفاً في كل سبرنت وإتماماً أوسع لكل إصدار، ويكفي الإصلاحَ العاجل (Hotfix) إتمامٌ صغير.

المحفّز المعتاد هو أن معايير الخروج (Exit Criteria) في خطة الاختبار قد قُيّمت. وقد يتوقف الاختبار قبل ذلك: فحين ينفد الوقت أو الميزانية، يقبل منهج CTFL الإصدار ⁦4.0⁩ إنهاء الاختبار إذا راجع أصحاب المصلحة خطر الإطلاق دون مزيد من الاختبار وقبلوه، وقد يُلغى المشروع. وعندها يصبح الإتمام أهم، لأن التقرير يجب أن يذكر بوضوح ما لم يُنجَز. أما التوقف المؤقت فأمر مختلف: إنه تعليق للاختبار لا إتمام له.

مهام الإتمام الخمس

يسرد منهج CTFL الإصدار ⁦4.0⁩ خمس مهام لإتمام الاختبار (وكانت المناهج الأقدم تسميها أنشطة إغلاق الاختبار)، ويصف معيار ⁦ISO/IEC/IEEE 29119-2⁩ عمليةً لإتمام الاختبار لها الجوهر نفسه: أرشفة أصول الاختبار، وتنظيف بيئة الاختبار، واستخلاص الدروس المستفادة، وإعداد التقرير. وكل مهمة تجيب عن سؤال واحد.

  • العيوب غير المحلولة: ماذا نفعل بها؟ لكل عيب منها مالك وقرار مسجَّل يتخذه عادةً مالك المنتج: إما تأجيله (Deferred) إلى إصدار لاحق، فيصبح طلب تغيير أو عنصراً في قائمة مهام المنتج ويُدرج في قائمة المشكلات المعروفة؛ وإما إغلاقه بقرار «لن يُصلَح» (Won't fix)، وهو عيب حقيقي يُقبل بقرار عمل؛ وإما رفضه (Rejected) لأنه تبيّن أنه ليس عيباً.
  • مواد الاختبار: ما الذي يستحق الحفظ؟ تُؤرشف أو تُسلَّم حالات الاختبار والاختبارات المؤتمتة وبيانات الاختبار وسكربتاتها وإعدادات البيئة وملاحظات الجلسات التي ستفيد لاحقاً، وتُوقف اختبارات الميزات التي أُزيلت.
  • بيئة الاختبار: في أي حالة نتركها؟ أوقفها أو أعدها إلى الحالة المتفق عليها مع مالكيها: حالة أساسية معروفة، أو محفوظة لاختبار الإصلاحات العاجلة، أو مسلَّمة إلى فريق آخر. واحذف الحسابات والصلاحيات المؤقتة ونسخ البيانات الشخصية.
  • الدروس المستفادة: ما الذي نغيّره في المرة القادمة؟ حلّل ما أبطأ الاختبار، وأي العيوب اكتُشفت متأخرة أو تسرّبت إلى بيئة الإنتاج، وكيف جاء الجهد الفعلي مقارنةً بالتقدير. وتصبح كل ملاحظة إجراء تحسين له مالك.
  • تقرير إتمام الاختبار: ما الذي يحتاج أصحاب المصلحة إلى معرفته؟ الاختبار مقابل الخطة، والانحرافات، والعيوب التي لم تُصلَح، والمخاطر غير المعالَجة، والمقاييس، والدروس المستفادة، ويُرسل إلى أصحاب المصلحة. يشرح درس تقارير الاختبار محتواه، والإتمام هو وقت كتابته.
إتمام الاختبار خطوة بخطوة: من بلوغ المعلَم مروراً بالعيوب المفتوحة ومواد الاختبار والبيئة والدروس المستفادة حتى تقرير الإتمام والتسليم. نموذج مفاهيمي
  1. 1بلوغ المعلَمإصدار أو نهاية سبرنت أو مستوى اختبار؛ قُيّمت معايير الخروج أو سُجّل قرار بالتوقفالمحفّز
  2. 2حسم العيوب المفتوحةلكل عيب مالك وقرار: يؤجَّل إلى قائمة المهام، أو «لن يُصلَح»، أو يُرفض
  3. 3أرشفة مواد الاختبار أو تسليمهااحفظ ما يُعاد استخدامه وأوقف ما تقادم
    في الوقت نفسه
    • 4إعادة بيئة الاختبارحالة متفق عليها، مع حذف الحسابات المؤقتة والبيانات الشخصية
  4. 5استخلاص الدروس المستفادةكل ملاحظة تصبح إجراءً له مالك
  5. 6كتابة تقرير الإتمام وإرسالهمقابل الخطة: الانحرافات والعيوب المفتوحة والمخاطر المتبقية
  6. 7التسليمالمشكلات المعروفة للدعم، وفحوص الدخان للتشغيل، وحزمة الانحدار للصيانة

بعد ذلك:إلى الدورة التالية: مواد الاختبار المؤرشفة وإجراءات التحسين نقطة انطلاقها

ترتيب معتاد: كثيراً ما تتداخل المهام، ويُتفق على التسليم مع الفرق المستلمة قبل الإصدار.

جرّبها: تحويل Markdown إلى PDF

التسليم إلى فرق التشغيل والدعم والصيانة

يذكر منهج CTFL الإصدار ⁦4.0⁩ أن مواد الاختبار قد تُسلَّم إلى الفرق المعنية. وبعد الإصدار تكون هذه الفرق عادةً فريقَ التشغيل وفريقَ الدعم ومن يتولى صيانة المنتج. ويكتمل التسليم حين يستطيع الفريق المستلم استخدام ما تسلّمه دون أن يسأل المختبِر عن معناه، لذا اتفق معه عليه قبل الإصدار.

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

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

مثال تطبيقي: إغلاق الإصدار ⁦3.4⁩ لصفحة الدفع

يطلق تطبيق لتوصيل الطعام الإصدار ⁦3.4⁩: تُضاف مدفوعات المحفظة الإلكترونية، وتحل شاشة قسائم جديدة محل القديمة، ويُلغى الدفع عند الاستلام. معايير الخروج: اختبار كل متطلب عالي المخاطر، وعدم وجود عيب مفتوح بخطورة حاجب (Blocker) أو حرج (Critical)، ونجاح حزمة الانحدار. نُفّذت ⁦186⁩ حالة اختبار من ⁦192⁩ حالة مخططة، واستبعد مالك المنتج من النطاق ست حالات منخفضة المخاطر للمحفظة لأن بيئة الاختبار المعزولة (Sandbox) لدى مزوّد المحفظة توقفت يومين، فبقي معيار المتطلبات عالية المخاطر متحققاً.

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

سجل إتمام الاختبار: الإصدار 3.4 (صفحة الدفع)

المحفّز: قرار الإطلاق بعد تقييم معايير الخروج
التنفيذ: 186 من 192 حالة اختبار، و6 حالات محفظة منخفضة المخاطر مستبعدة
  (توقف Sandbox المحفظة يومين)، وقبل مالك المنتج المخاطر المتبقية كتابةً
العيوب:
- DEF-481 (Major) الخصم يظهر مرتين بعد إعادة تطبيق القسيمة؛
  نُقل إلى PB-902، والحل البديل: إزالة القسيمة ثم تطبيقها مجدداً
- DEF-487 (Minor) رسالة الإيصال تعرض التاريخ بتنسيق خاطئ؛ نُقل إلى PB-903
مواد الاختبار:
- دُمج 38 اختبار API جديداً في حزمة الانحدار
- وُسم سكربت بيانات الاختبار بالوسم release-3.4 وأُرشف
- أُوقفت 6 اختبارات للدفع عند الاستلام (أُزيلت الميزة)
البيئة: أُعيدت Staging إلى الحالة الأساسية، وحُذفت 4 حسابات مشرفين مؤقتة
الدروس المستفادة:
- ضاع يومان بسبب توقف Sandbox؛ الإجراء: حجز Sandbox في خطة الاختبار
  (المالك: قائد QA)
- تسرّب DEF-455 من الإصدار 3.3؛ الإجراء: أُضيف اختبار انحدار (المالك: المختبِر)
التقرير: أُرسل إلى مالك المنتج وقائد التطوير وقائد الدعم
التسليم:
- الدعم: المشكلتان المعروفتان DEF-481 وDEF-487 مع الحل البديل
- التشغيل: فحوص الدخان، ومراقبة نسبة فشل المدفوعات لمدة 48 ساعة

أخطاء شائعة

  • تخطي الإتمام لأن الإصدار خرج والسبرنت التالي بدأ.
  • ترك العيوب غير المُصلَحة مفتوحة بلا قرار ولا مالك.
  • أرشفة كل شيء، بما فيه الاختبارات المتقادمة، فلا يعيد أحد استخدام الأرشيف؛ أو عدم أرشفة أي شيء خارج المجلدات الشخصية.
  • كتابة الدروس المستفادة شكاوى («البيئة كانت سيئة») دون إجراء ومالك وموعد.
  • ترك الحسابات المؤقتة والصلاحيات ونسخ البيانات الشخصية في بيئة الاختبار.
  • التسليم برابط يُرسَل في اليوم الأخير، دون الاتفاق على ما يحتاجه الفريق المستلم.

من منظور ضمان الجودة

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

اعمل مع مالك المنتج على قرارات العيوب، ومع قائد التطوير ومهندس DevOps على البيئة وحزمة الانحدار، ومع فريقي الدعم والتشغيل على التسليم. وسجّل كل قرار باسم صاحبه وتاريخه، مثل «قبل مالك المنتج الإصدار مع بقاء DEF-481 مفتوحاً»، واحفظ التقرير حيث سيبحث المختبِر التالي أولاً. وفي نقاش الدروس المستفادة اسأل: ما الذي نستمر في فعله؟ وما الذي أبطأنا؟ وأي العيوب كان يجب أن نكتشفها أبكر؟

تمرين عملي

أغلق اختبار سبرنت

المطلوب

أنهى فريقك السبرنت ⁦14⁩ لتطبيق صيدلية إلكترونية، والحالة أدناه. اكتب إتمام الاختبار لهذا السبرنت، بما في ذلك ما يجب أن يذكره تقرير الإتمام عن الاختبارات التي لم تُنفَّذ.

المادة
السبرنت 14: رفع الوصفات الطبية

حالات الاختبار المخططة: 64؛ المنفَّذة: 60؛ غير المنفَّذة: 4
  (التعرّف على الوصفات المكتوبة بخط اليد: خدمة OCR لم تكن جاهزة)
العيوب المفتوحة:
- DEF-210 (Major) يفشل رفع ملفات PDF التي يزيد حجمها على 8 MB
- DEF-214 (Minor) أسماء الملفات العربية تظهر علامات استفهام في سجل الطلبات
- DEF-219 (Trivial) أيقونة زر الرفع منزاحة على الشاشات الصغيرة
مواد الاختبار الجديدة: 22 حالة اختبار يدوية، و9 اختبارات API مؤتمتة،
  و12 ملف وصفة نموذجياً (3 منها صور ممسوحة لوصفات حقيقية)
البيئة: Staging مشتركة؛ أُنشئت 3 حسابات صيادلة مؤقتة للاختبار
ملاحظات: ضاع يوم ونصف في انتظار خدمة OCR؛
  وأبلغ عميل عن DEF-201 من السبرنت 13 بعد الإصدار
الخطوات
  1. قرّر مصير كل عيب مفتوح ومن يقرر.
  2. اكتب مواد الاختبار التي تُحفظ أو تُؤرشف أو تُوقف.
  3. حدّد الحالة النهائية للبيئة.
  4. اكتب درسين مستفادين، لكل منهما إجراء ومالك.
  5. بيّن من يتسلّم ماذا في التسليم، وماذا يذكر التقرير عن الاختبارات الأربعة التي لم تُنفَّذ.
إظهار الإجابة النموذجية
الإجابة النموذجية

العيوب: يصبح DEF-210 (رئيسي Major) عنصراً في قائمة مهام المنتج يحدد مالك المنتج أولويته، وإلى أن يُصلَح يعطي فريق الدعم المستخدمين الحل البديل «ارفع ملفات أصغر من ⁦8⁩ MB». ويصبح العيبان DEF-214 (ثانوي Minor) وDEF-219 (تافه Trivial) عنصرين في القائمة، أو يغلق مالك المنتج DEF-219 بقرار «لن يُصلَح» (Won't fix) ويسجّل سببه.

مواد الاختبار: احفظ حالات الاختبار اليدوية وعددها ⁦22⁩، وأضف إلى حزمة الانحدار اختبارات API التسعة واختباراً للعيب المتسرّب DEF-201، وأرشف حالات OCR الأربع جاهزةً للتنفيذ. وضع ملفات اصطناعية مكان الصور الممسوحة الثلاث للوصفات الحقيقية واحذف الصور، فالبيانات الصحية الشخصية لا تُؤرشف.

البيئة: احذف حسابات الصيادلة المؤقتة الثلاثة وأي نسخ مرفوعة من الصور الممسوحة للوصفات الحقيقية، واترك بيئة Staging المشتركة في حالتها الأساسية المتفق عليها.

الدروس المستفادة: «ضاع يوم ونصف في انتظار OCR» ← التأكد من توفر خدمات الأطراف الثالثة في تخطيط السبرنت (المالك: قائد QA). «تسرّب DEF-201» ← تحديد شرط الاختبار المفقود وإضافته (المالك: المختبِر).

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

أسئلة شائعة

هل إتمام الاختبار هو نفسه إغلاق الاختبار؟

عملياً نعم. «إغلاق الاختبار» و«إغلاق دورة الاختبار» اسمان أقدم أو متداولان في الصناعة للعمل نفسه، ويسميه منهج ISTQB CTFL الإصدار ⁦4.0⁩ إتمام الاختبار. ومُخرَجه الرئيسي تقرير إتمام الاختبار، الذي تسميه المصادر الأقدم تقرير ملخص الاختبار (Test Summary Report)، ويعرّفه معيار ⁦ISO/IEC/IEEE 29119-3⁩ ضمن وثائق إدارة الاختبار.

هل تُجري الفرق الرشيقة إتمام الاختبار؟

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

ماذا لو توقف الاختبار قبل تحقق معايير الخروج؟

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

المراجع

الأدوات

تدرّب بأدوات متقن

المتطلبات ← حالات اختبار

حوّل قائمة متطلبات مرقّمة إلى حالات اختبار قابلة للتتبّع مع مصفوفة تربط المتطلبات بالاختبارات.

تصميم الاختبارات

تحويل Markdown إلى PDF

حوّل ملفات Markdown (md.) إلى PDF في متصفحك: العناوين والقوائم والجداول وكتل الشيفرة والاقتباسات والروابط والصور منسّقة بخطوط مضمّنة.

تحويل PDF

للتعمّق أكثر

تقدّمك في هذا الموضوع

جزء من مسار تعلم ضمان الجودة

قبل هذا الموضوع

الموضوعات التالية