مصفوفة اختبار الإصدار الجيدة لا تقول إن المنتج يعمل على «جميع الأجهزة». تحدد تركيبات الأجهزة وأنظمة التشغيل والمتصفحات التي التزم الفريق بفحصها، والرحلات التي اختُبرت عليها، والنتيجة لكل إصدار. ابدأ بجمهورك الفعلي ومهامه ومخاطر تعطله، ثم اختر تغطية تستطيع تنفيذها والدفاع عن سبب اختيارها.
في نطاق اختبار وضمان جودة البرمجيات، المخرج المفيد هو دليل اختبار قابل للتتبع، وليس صورة للشاشة على مقاسات متعددة فقط. قد يبدو النموذج سليماً على الجوال بينما تمنع لوحة المفاتيح المستخدم من الوصول إلى زر الإرسال أو تفشل استعادة الجلسة.
اجمع ما يبرر اختيار البيئات
راجع بيانات الاستخدام المأذونة إن توفرت، وتذاكر الدعم، والأجهزة المعتمدة للموظفين، ومتطلبات الجهات التي ستستخدم المنتج. افصل بيانات الجمهور الحالي عن جمهور مستهدف لم يبدأ الاستخدام بعد. انخفاض الزيارات من جهاز قد يعكس مشكلة تمنع أصحابه من الدخول، فلا تعتبره دائماً دليلاً على عدم أهميتهم.
عند غياب بيانات كافية، سجل الاختيار كافتراض أولي، وحدد كيف ستراجعه بعد ظهور الأدلة. لا تستورد قائمة أجهزة رائجة من سوق آخر وتقدمها باعتبارها جمهور العميل. كذلك يجب التحقق من نسخ المنصات التي يدعمها المنتج فعلياً وقت الإطلاق؛ لا تعتمد أرقام إصدارات محفوظة من مشروع سابق.
يشير دليل MDN للاختبار عبر المتصفحات إلى ضرورة الاتفاق على نطاق الدعم، وإلى أن اختلاف العرض لا يقتضي دائماً اختلاف الوظيفة الأساسية. المطلوب نتيجة مهمة متاحة للمستخدم، لا تطابق كل بكسل بين البيئات.
ما الذي تسجله في كل خانة؟
لا تكفي كلمة «جوال». سجل الجهاز أو فئته، ونظام التشغيل ونسخته، والمتصفح ونسخته، وطريقة الاختبار الفعلية، وحجم العرض عند أهميته. أضف نسخة التطبيق، ودور المستخدم، والبيانات الابتدائية، والرحلة والنتيجة المتوقعة. بهذه التفاصيل يستطيع المطور إعادة المشكلة بدلاً من تخمين البيئة.
اجعل مستويات الفحص معلنة. قد تشمل مجموعة أساسية جميع الرحلات الحرجة قبل الإصدار، ومجموعة أخرى فحصاً أضيق أو دورياً، وحالات خاصة عند تغيير وظيفة تعتمد على المنصة. لا تسمِّ المجموعة الثانية «مدعومة بالكامل» إذا لم تختبر عليها ما توحي به العبارة.
والفرق بين جهاز فعلي ومحاكاة يجب أن يبقى ظاهراً في سجل الدليل. يمكن استخدام كل منهما لغرض مناسب، لكن لا تحوّل نتيجة المحاكاة إلى ادعاء عن اختبار جهاز لم يتوفر للفريق.
مثال افتراضي: بوابة طلب خدمات
لنفترض أن بوابة تخدم موظفي مكاتب وفنيين ميدانيين. توضح سجلاتها المأذونة أن مستخدمي المكتب يعتمدون حواسيب محددة، بينما يعمل الفنيون على مجموعتين معروفتين من الهواتف. يختار الفريق ثلاث تركيبات أساسية موثقة بالإصدارات الفعلية، ويختبر عليها تسجيل الدخول وإنشاء طلب وإرفاق صورة ومتابعة الحالة.
ثلاث تركيبات مضروبة في أربع رحلات تعني 12 خانة أساسية. يضيف الفريق تركيباً مكتبياً ثانوياً لفحص رحلتين، فيصبح إجمالي الخانات المخططة 14. إذا نجحت 13 خانة وتعذر اختبار إرفاق الصورة على إحدى مجموعتي الهواتف، فلا يعلن الفريق اكتمال التغطية أو يحوّل النتيجة إلى نجاح بنسبة مطمئنة.
يسجل أن رحلة مهمة لم تُختبر، ويطلب الجهاز المناسب أو يتخذ صاحب القرار قراراً صريحاً بشأن التأجيل أو تقييد الإطلاق. الأرقام هنا للتوضيح، وليست الحد الأدنى لاختبار بوابة أو توزيعاً مستنداً إلى سوق سعودي.
اختبر المهمة مع ظروف استخدامها
بالإضافة إلى المسار العادي، جرّب تغيير اتجاه الشاشة عندما يؤثر، وظهور لوحة المفاتيح، وانقطاعاً معقولاً في الشبكة داخل بيئة الاختبار، والعودة من تطبيق آخر، وإلغاء إذن مطلوب. اختَر الحالات المرتبطة بالمهمة؛ لا تضاعف المصفوفة بكل احتمال دون مبرر.
إذا تعلقت المشكلة بتصرف الواجهة على الهاتف، يعود القرار إلى مواصفات تصميم تطبيقات الجوال عندما تكون ضمن نطاق المنتج. وفي واجهات الويب، توضح مخرجات تصميم المواقع الإلكترونية السلوك المتجاوب وحالات العناصر. أما إصلاح التطبيق أو سلوكه في المنصة فيتطلب نطاق تطوير التطبيقات المناسب، لا تعديل صورة التصميم فقط.
لا تخلط الفحص الوظيفي مع تدقيق وصول شامل. يمكن أن تتضمن الرحلة استخدام لوحة المفاتيح أو تكبير المحتوى، لكن اختبارات التقنيات المساعدة ومعايير الوصول تحتاج نطاقها ومختصيها وأدلتها إذا كانت مطلوبة.
كيف يُتخذ قرار الإصدار؟
اتفق قبل التنفيذ على الخانات التي تمنع الإطلاق عند الفشل أو عدم الاختبار. ميّز بين «ناجح» و«فاشل» و«لم يختبر» و«مستثنى بقرار». الاستثناء يحتاج سبباً ومالكاً وحداً واضحاً، ولا يعيد تسمية الفشل نجاحاً.
بعد الإصلاح، أعد الحالة على البيئة التي ظهر فيها العيب، ثم افحص التأثيرات القريبة بحسب التغيير. احتفظ برقم النسخة؛ نتيجة على بناء قديم لا تثبت بناءً جديداً تلقائياً. وإذا تغير المتصفح أو نظام التشغيل أثناء المشروع، راجع المصفوفة بدل افتراض ثبات البيئة.
التسليم الجيد يضم المصفوفة المنفذة، وأدلة العيوب المهمة، ونتائج إعادة الاختبار، والبيئات المستبعدة وأسبابها. هذا يمنح فريق الدعم حدوداً مفهومة عند وصول بلاغ من تركيبة لم تدخل الاختبار.
أسئلة شائعة
هل نختبر أكثر المتصفحات انتشاراً فقط؟
استخدم الانتشار كأحد المدخلات، مع أثر الفشل والتزامات المنتج وجمهوره. جهاز قليل الاستخدام لكنه أساسي لفريق ميداني قد يستحق أولوية عالية.
هل تصغير نافذة المتصفح يكفي للجوال؟
يساعد في فحص التخطيط، لكنه لا يثبت تجربة جهاز فعلي بمدخلاته وظروفه. سجّل نوع الدليل وحدوده، واختر فحصاً يناسب المخاطر.
هل يجب أن تتطابق الواجهة تماماً؟
حدد الفروق المقبولة مع التصميم، بشرط بقاء المهمة والمعلومات الضرورية قابلة للاستخدام. لا تجعل اختلافاً شكلياً صغيراً يخفي عطلاً وظيفياً أهم.
ماذا نفعل ببيئة لم نستطع توفيرها؟
سجلها غير مختبرة، ثم وفّر الوصول أو عدّل نطاق الدعم بقرار مسؤول. لا تكتب أنها نجحت استناداً إلى بيئة أخرى دون دليل.
أرسل قائمة الرحلات الحرجة وما تعرفه عن أجهزة المستخدمين. يمكن عندها بناء مصفوفة اختبار واضحة الحدود بدلاً من وعد غير قابل للإثبات بتوافق شامل.
المصدر
- MDN: مقدمة الاختبار عبر المتصفحات، روجعت في 26 أكتوبر 2026. المصفوفة العددية افتراضية.
