هل المنتج جاهز للإطلاق؟ دليل الـQA لتقييم الإصدار

هل المنتج جاهز للإطلاق؟

«خلصتوا التست؟ نقدر نرفع النسخة؟»

سؤال يتكرر قبل الإطلاق، لكن الإجابة لا تعتمد على عدد الاختبارات المنفّذة فقط. قد تنجح معظم الاختبارات، بينما تبقى مشكلة واحدة تمنع المستخدم من الدفع أو تكشف بيانات حساب آخر.

دور الـQA هو تقديم صورة واضحة: ما الذي اختُبر؟ ما المشاكل المتبقية؟ وما المخاطر التي سيتحمّلها الفريق إذا أطلق الإصدار؟

1. اتفق على معايير الجاهزية مسبقًا

حدّد مع الفريق شروط قبول الإصدار قبل الوصول إلى موعد إطلاقه. تساعد معايير الخروج من الاختبار (Exit Criteria) على معرفة متى اكتملت أنشطة الاختبار بالمستوى المطلوب، لكنها ليست وحدها كل شروط جاهزية المنتج.

من أمثلة المعايير التي يمكن الاتفاق عليها:

• نجاح اختبارات المسارات الأساسية.
• عدم وجود أخطاء مفتوحة تمنع الإطلاق وفق سياسة الفريق.
• إعادة اختبار الإصلاحات المهمة.
• تنفيذ Regression Testing للمناطق المتأثرة.
• استيفاء متطلبات الأداء والأمان ذات الصلة.
• توثيق المخاطر والاستثناءات والحصول على قبول أصحاب الصلاحية.

لا توجد نسبة نجاح واحدة تصلح لكل المنتجات؛ اربط المعايير بطبيعة المنتج ومخاطره.

2. ابدأ برحلات المستخدم المهمة

اسأل: هل يستطيع المستخدم إكمال المهمة الأساسية من البداية إلى النهاية؟

في تطبيق حجوزات مثلًا، قد تشمل الرحلة:

تسجيل الدخول ← اختيار الخدمة ← الحجز ← الدفع ← ظهور التأكيد.

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

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

3. قيّم أثر الأخطاء، لا عددها فقط

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

لكل مشكلة مفتوحة، وضّح:

• الأثر: ما الضرر الذي تسببه؟
• نطاق التأثر: من المستخدمون أو الأجهزة المتأثرة؟
• احتمال الحدوث: هل تظهر في مسار شائع أم حالة نادرة؟
• الحل البديل: هل يستطيع المستخدم إكمال مهمته بطريقة مقبولة؟
• قابلية الاكتشاف والتعافي: هل سنلاحظ المشكلة سريعًا ونستطيع التعامل معها؟

تصنيف Severity يساعد على النقاش، لكن وصف الأثر الفعلي هو ما يجعل القرار مفهومًا.

4. تأكد من النسخة التي اختبرتها

قد تكون نتائج الاختبار ممتازة، لكنها تخص نسخة سابقة!

اربط التقييم برقم Build محدد، وبيئة اختبار معروفة، وإعدادات واضحة. وإذا أُضيف تغيير بعد انتهاء الاختبار، قيّم أثره وحدّد الاختبارات المطلوب تكرارها.

تحقّق أيضًا من الفروق المؤثرة بين بيئة الاختبار والإنتاج: إعدادات الدفع، والصلاحيات، والخدمات الخارجية، وFeature Flags، وترحيل البيانات عند وجوده.

نجاح نسخة لا يعني تلقائيًا أن نسخة أحدث جاهزة.

5. وضّح ما لم تختبره

تقرير الجاهزية يجب أن يُظهر حدود الثقة، لا النتائج الناجحة فقط.

اذكر الاختبارات المحجوبة Blocked، والحالات غير المنفّذة Not Run، والأجهزة غير المغطّاة، وأي خدمة خارجية لم تكن متاحة.

مثلًا، عبارة «نجحت 95% من الاختبارات» قد تكون مضللة إذا كانت اختبارات الدفع ضمن النسبة المتبقية. اعرض الأعداد والنطاق وأهمية الحالات، بدل الاعتماد على النسبة وحدها.

6. راجع الاستعداد لما بعد النشر

بالتعاون مع التطوير والتشغيل والمنتج، تأكد من وجود:

• فحص سريع للمسارات الأساسية بعد النشر Smoke Testing.
• مراقبة للأخطاء والمؤشرات المهمة.
• مسؤول واضح لمتابعة الإصدار.
• خطة تعامل مع المشاكل ومعايير لإيقاف التوسع في الإطلاق.
• خطة تراجع أو معالجة قابلة للتنفيذ، خصوصًا عند تغيير البيانات.

لا تفترض أن الرجوع إلى النسخة السابقة سيعيد البيانات تلقائيًا إلى حالتها القديمة.

مثال عملي على قرار الإطلاق

لنفترض تنفيذ 100 اختبار: نجح 98 وفشل اختباران.

الاختبار الأول كشف خطأ في محاذاة عنوان، والثاني كشف احتمال خصم المبلغ مرتين عند إعادة محاولة الدفع.

رغم نجاح 98% من الاختبارات، فالتوصية المناسبة هنا No-Go حتى معالجة خطر الدفع والتحقق من الإصلاح. أهمية الاختبار الفاشل أكبر من النسبة الإجمالية.

كيف يكتب الـQA توصيته؟

استخدم ملخصًا واضحًا مثل:

الإصدار: رقم النسخة والـBuild. النطاق المختبَر: الميزات والرحلات والأجهزة المشمولة. النتائج: الناجح والفاشل والمحجوب وغير المنفّذ. المشاكل والمخاطر: أثرها، والحلول البديلة، والمسؤول عن قبولها. التوصية: Go أو No-Go، أو إطلاق مشروط بإجراءات محددة.

الـQA يقدّم التوصية والأدلة، أما قرار الإطلاق فيتخذه أصحاب الصلاحية وفق آلية الفريق. وإذا كانت الموافقة مشروطة، يجب تحديد الشروط والتحقق منها قبل التنفيذ.

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