اختبار الصيانة

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

مثال ذلك نظام حجز مواعيد لعيادات يعمل منذ أربع سنوات، ويُنقل إلى خادم قاعدة بيانات جديد. لا تتغير أي ميزة، ومع ذلك يجب على الفريق أن يتحقق من وصول كل سجل سليماً، ومن أن الحجز والتذكيرات والفواتير تعمل كما كانت. واختبار الصيانة ليس مستوى اختبار مستقلاً، بل يعيد استخدام المستويات والأنواع التي تعرفها، مثل اختبار التأكيد (Confirmation Testing) واختبار الانحدار (Regression Testing).

لماذا يهم

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

ثلاثة محفّزات: التعديل والترحيل والإخراج من الخدمة

يجمع منهج ISTQB للمستوى التأسيسي الأحداث التي تستدعي اختبار الصيانة في ثلاثة محفّزات (Triggers). وأياً كان المحفّز، يجيب الاختبار عن سؤالين: هل نجح التغيير؟ وهل انكسر شيء آخر؟ أما المحفّز فيدلّك على موضع البحث.

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

تتبع الصفوف المحفّزات الثلاثة في منهج ISTQB للمستوى التأسيسي، والخلايا تلخّص هذا الدرس وليست قائمة تحقق ثابتة.

تحليل الأثر: ما الذي قد يتأثر بهذا التغيير؟

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

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

جرّبها: المتطلبات ← حالات اختبار

تحديد نطاق الانحدار

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

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

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

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

مثال تطبيقي: إصلاح التذكيرات في نظام حجز قيد التشغيل

يرسل نظام الحجز لدى مجموعة عيادات رسالة تذكير نصية قبل ⁦24⁩ ساعة من كل موعد، لكن الفروع الواقعة في منطقة زمنية ثانية تتلقاها في ساعة خاطئة، لأن المهمة تعتمد على ساعة الخادم. والإصلاح التصحيحي يستخدم المنطقة الزمنية لكل فرع، ويملأ حقلاً جديداً time_zone لكل فرع قائم؛ أما التذكيرات التي جدولها الإصدار القديم فتبقى في قاعدة البيانات. وقد أعطى تحليل الأثر مع المطوّر هذا النطاق:

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

جرّبها: مقارنة استجابات API جرّبها: مقارنة JSON

أخطاء شائعة

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

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

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

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

تمرين عملي

حدّد نطاق الاختبار لطلب تغيير من ثلاثة أجزاء

المطلوب

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

المادة
طلب التغيير CR-118 (نظام مكتبة، قيد التشغيل منذ ست سنوات)

1. ترتفع غرامة التأخير في الإرجاع من 1.00 ريال إلى 2.00 ريال يومياً،
   للإعارات التي تبدأ في 1 يناير أو بعده.
2. يُخرَج تطبيق أكشاك الخدمة الذاتية من الخدمة، ويستخدم الأعضاء مكتب الاستقبال بدلاً منه.
   ويجب أن تبقى سجلات الإعارة والدفع في الأكشاك لآخر خمس سنوات قابلة للاسترجاع للتدقيق.
3. ينتقل التطبيق إلى إصدار رئيسي جديد من خادم التطبيقات الذي يعمل عليه.
الخطوات
  1. صنّف كل بند: تعديل، أو ترقية للبيئة أو ترحيل، أو إخراج من الخدمة.
  2. اكتب ما يمسّه كل تغيير مباشرةً، وما يعتمد عليه، ومحور الاختبار: التغيير نفسه، أو الانحدار، أو البيئة، أو البيانات، أو الأرشيف.
  3. قرّر النطاق الإجمالي، وما هو خارج النطاق، وأسئلتك المفتوحة.
إظهار الإجابة النموذجية
الإجابة النموذجية

البند ⁦1⁩ تعديل لحساب الغرامة، وتعتمد عليه إشعارات التأخير وأرصدة الأعضاء وتقرير الغرامات. اختبر الحدّ: إعارة تبدأ في ⁦31⁩ ديسمبر تبقى غرامتها ⁦1.00⁩ ريال يومياً حتى لو تأخرت في يناير، وإعارة تبدأ في ⁦1⁩ يناير غرامتها ⁦2.00⁩. والاختبارات التي تتوقع ⁦1.00⁩ للإعارات الجديدة يجب تحديثها.

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

البند ⁦3⁩ ترقية للبيئة: اختبر التثبيت والإعدادات، والاتصال بخدمتي البريد الإلكتروني والدفع، والمهمة الليلية لإشعارات التأخير، وأزمنة الاستجابة الرئيسية مقارنةً بخط الأساس القديم.

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

أسئلة شائعة

هل اختبار الصيانة هو نفسه اختبار الانحدار؟

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

من يجري تحليل الأثر: المطورون أم المختبِرون؟

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

هل يحتاج الإصلاح العاجل إلى اختبار انحدار رغم الاستعجال؟

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

ماذا لو لم يكن للنظام القديم وثائق ولا اختبارات؟

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

المراجع

  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
  • ISTQB GlossaryISTQBالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.

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

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

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

قارن استجابتي API (مثل بيئة التجريب مقابل الإنتاج) واحصل على قائمة بكل فرق بنيوي أو في القيم.

اختبار واجهات API

مقارنة مستندي JSON دلالياً وإبراز القيم المضافة والمحذوفة والمتغيرة.

JSON والبيانات

للتعمّق أكثر

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

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