تجزؤ الأجهزة

لماذا يهم

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

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

من أين يأتي التجزؤ

تناول درس Android وiOS إصدارات النظام ونسخ المتاجر. أما في بقية الأبعاد فالتنوع الأوسع في Android، لأن شركات مصنّعة كثيرة تطرحه على عتاد يمتد من الأجهزة الاقتصادية إلى الرائدة، وتضيف كل منها طبقة نظام خاصة بها. ويعمل iOS على طرازات أقل، لكن عدة أحجام من iPhone، وأجهزة iPad إن كان التطبيق يدعمها، تبقى مستخدمة في الوقت نفسه.

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

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

أحجام الشاشات: البكسلات والكثافة وفئات الحجم

لا تُبنى تخطيطات التطبيقات بالبكسلات بل بوحدات مستقلة عن الكثافة: dp على Android وpoints على iOS. والـ dp الواحدة تساوي بكسلاً فعلياً واحداً على شاشة كثافتها ⁦160 dpi⁩، فالعرض بوحدات dp هو العرض بالبكسلات × ⁦160⁩ ÷ الكثافة. فهاتف عرضه ⁦1080⁩ بكسلاً بكثافة ⁦420 dpi⁩ عرضه نحو ⁦411 dp⁩، وهاتف عرضه ⁦720⁩ بكسلاً بكثافة ⁦320 dpi⁩ عرضه ⁦360 dp⁩. وترسم أجهزة iPhone كل point ببكسلين أو ثلاثة في كل اتجاه (@2x و@3x). فالعرض بوحدات dp أو points، لا دقة الشاشة، هو ما يحدد ما يتسع على الشاشة.

تتبدّل التخطيطات المتكيّفة عند عتبات. ففئات حجم النافذة (Window Size Classes) في Android للعرض هي: المضغوطة (Compact) دون ⁦600 dp⁩، وتشمل كل الهواتف تقريباً في الوضع العمودي؛ والمتوسطة (Medium) من ⁦600⁩ إلى ⁦839 dp⁩، وتشمل معظم الأجهزة اللوحية والأجهزة القابلة للطي المفتوحة في الوضع العمودي؛ والموسّعة (Expanded) من ⁦840⁩ إلى ⁦1199 dp⁩، وتشمل معظم الأجهزة اللوحية في الوضع الأفقي؛ وللنوافذ الأعرض فئات خاصة بها. وفي iOS يوصف كل محور بأنه مضغوط (Compact) أو عادي (Regular): فجهاز iPhone في الوضع العمودي عرضه مضغوط وارتفاعه عادي، وتطبيق iPad بملء الشاشة عادي في المحورين، لكنه يصبح مضغوط العرض في نافذة تعدد مهام ضيقة. وكل عتبة حدّ، فطبّق درس تحليل القيم الحدّية: اختبر ⁦599⁩ و⁦600 dp⁩، و⁦839⁩ و⁦840 dp⁩.

والعرض ليس القيد الوحيد. فشريطا الحالة والتنقل وفتحات الكاميرا ومؤشر الشاشة الرئيسية في iPhone تأخذ مساحة، ويجب أن يبقى المحتوى داخل المنطقة الآمنة (Safe Area)؛ والتطبيقات التي تستهدف Android 15 تُعرض من الحافة إلى الحافة (Edge-to-edge) افتراضياً، فقد يُخفي تحديثُ الإصدار المستهدف (Target SDK) زراً تحت شريط التنقل. وتُضيّق إعدادات المستخدم المساحة أكثر: فإعداد حجم العرض في Android يغيّر العرض بوحدات dp، وتكبير الخط حتى ⁦200%⁩ (في Android 14 وما بعده) أو أكبر أحجام Dynamic Type في iOS يقلّل كثيراً ما يتسع على الشاشة من نص.

• أصغر عرض وأكبر عرض في المصفوفة: لا نص مقصوص، ولا عناصر متداخلة، ولا تمرير جانبي.
• جانبا كل عتبة: يتبدّل التخطيط كما صُمّم، مثل الانتقال إلى لوحين متجاورين ابتداءً من ⁦840 dp⁩.
• المنطقة الآمنة: لا عنصر قابلاً للنقر تحت شريط نظام أو فتحة كاميرا أو مؤشر الشاشة الرئيسية.
• أكبر خط وأكبر حجم عرض: يلتف النص بدلاً من أن يُقص، ويبقى كل إجراء في المتناول بالتمرير.

Width in dp = width in pixels × 160 ÷ density (dpi)

1080 px at 420 dpi  ->  ~411 dp   compact
1198 px at 320 dpi  ->   599 dp   compact  (just below the threshold)
1200 px at 320 dpi  ->   600 dp   medium   (first value of the class)

Android window size classes (width)
  compact    < 600 dp       almost all phones in portrait
  medium     600 - 839 dp   most tablets and unfolded foldables in portrait
  expanded   840 - 1199 dp  most tablets in landscape

On an Android emulator
  adb shell wm density 320
  adb shell wm size 1198x2000      # 599 dp, then 1200x2000 for 600 dp
  adb shell wm size reset && adb shell wm density reset

جرّبها: مولّد القيم الحدّية

الاتجاه وتغييرات التهيئة الأخرى

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

أما iOS فيُبقي الشاشة ويعيد ترتيب تخطيطها وفق الحجم الجديد، ووفق فئات الحجم الجديدة إن تغيّرت، لذا فعيوب التدوير في iOS غالباً عيوب تخطيط: زر مخفي، أو لوحة مفاتيح تغطي الحقل النشط. وفي الوضع الأفقي يصبح ارتفاع الهاتف صغيراً (فئة الارتفاع المضغوطة في Android دون ⁦480 dp⁩)، ومع فتح لوحة المفاتيح قد لا يظهر إلا حقل أو حقلان.

وقفل الشاشة على الوضع العمودي قرار منتج يُسجَّل، لا افتراض. فمعيار النجاح ⁦1.3.4⁩ الاتجاه (Orientation) في WCAG 2.2 (المستوى AA) لا يسمح به إلا إذا كان اتجاه معيّن ضرورياً. وفي التطبيقات التي تستهدف Android 16 يتجاهل النظام قيود الاتجاه وتغيير الحجم على الشاشات التي لا يقل أصغر عرض لها عن ⁦600 dp⁩، مع استثناءات مثل الألعاب، فيظهر التطبيق المقفل على الوضع العمودي أفقياً على الأجهزة اللوحية والأجهزة القابلة للطي المفتوحة.

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

اختيار مصفوفة الأجهزة

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

• البيانات: المستخدمون النشطون حسب إصدار النظام والطراز والشركة المصنّعة وفئة الشاشة، من أدوات التحليلات ولوحات المتاجر وتقارير الانهيار. وفي موقع الجوال تعطي سلاسل User-Agent في سجلات الخادم المتصفح ونوع الجهاز، لكن Chrome على Android صار يُبلغ عن إصدار Android وطراز ثابتين، فخذ هذين من أدوات التحليلات. والتطبيق الجديد يبدأ من سوقه المستهدفة.
• عناصر التغطية: أحدث نظام وأقدم نظام مدعوم في كل منصة، وأصغر عرض مستخدَم فعلاً وكل فئة حجم أكبر تدعمها، وجهاز قليل الذاكرة، والشركات المصنّعة الرائدة، وأكبر حجم خط، وكل اتجاه للنص.
• الأجهزة: فضّل الأجهزة التي تغطي عدة عناصر معاً، ثم أضف الطرازات صاحبة أكبر عدد من الجلسات وأي طراز تتجمّع عليه الانهيارات.
• الطبقات: أجهزة الطبقة 1 (Tier 1) حقيقية تُشغَّل عليها الرحلات الحرجة وحزمة الانحدار مع كل إصدار؛ والطبقة 2 على المحاكيات أو أجهزة مزرعة الأجهزة (Device Farm) ويُشغَّل عليها اختبار دخان مع كل إصدار؛ والطبقة 3 تُختبر قبل الإصدارات الكبرى.
• الإعدادات: وزّع اللغة والاتجاه وحجم الخط والمظهر على الأجهزة بالاختيار الثنائي (Pairwise) بدلاً من اختبار كل التركيبات.
• الصيانة: اكتب سبب وجود كل جهاز، وراجع المصفوفة كل ربع سنة وبعد كل إصدار نظام جديد أو حدّ أدنى جديد أو سوق جديدة.

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

مثال تطبيقي: تطبيق توصيل طعام

يدعم التطبيق Android 10 (API 29) وما بعده وiOS 17 وما بعده، ويعمل على iPhone فقط (لا نسخة لـ iPad)، ويُستخدم بالعربية والإنجليزية. بيانات توضيحية لآخر ⁦90⁩ يوماً: ⁦55%⁩ من الجلسات على Android، ثلاثة أرباعها على الشركتين المصنّعتين A وB؛ و⁦18%⁩ من جلسات Android على أجهزة ذاكرتها ⁦4⁩ غيغابايت أو أقل؛ وأصغر عرض مستخدَم ⁦360 dp⁩ على Android و⁦375⁩ point على iPhone؛ و⁦6%⁩ من جلسات Android على الأجهزة القابلة للطي واللوحية؛ و⁦70%⁩ من الجلسات بالعربية؛ وتجمّعٌ من الانهيارات على هواتف الشركة B عند عودة المستخدمين من صفحة الدفع.

تغطي خمسة أجهزة كل عناصر التغطية مرة واحدة على الأقل، كما يبيّن الشكل. والهاتف الاقتصادي D3 يؤدي العمل الأكبر، ولأنه من الشركة B فعليه يُشغَّل سيناريو «العودة من الدفع» أولاً. أما الشاشات الأعرض فلا يغطيها إلا الجهاز القابل للطي في مزرعة الأجهزة: خطر مقبول عند ⁦6%⁩ من جلسات Android، ومكتوب في المصفوفة. وفي الإعدادات، أربعة معاملات لكل منها قيمتان على خمسة أجهزة تعطي ⁦5 × 16 = 80⁩ تركيبة كاملة، بينما يمكن لمجموعة ثنائية أن تغطي كل زوج من القيم في ⁦10⁩ تشغيلات فقط.

• D1 وD2: أحدث نظام في كل منصة والطرازات صاحبة أكبر عدد من الجلسات؛ وD1 من الشركة A أيضاً.
• D3: أقدم Android مدعوم، وذاكرة قليلة، وأصغر عرض على Android، والشركة B وتجمّع انهياراتها.
• D4: أقدم iOS مدعوم وأصغر عرض على iPhone.
• D5: أحدث Android، والعرض المتوسط والموسّع، ونافذة يتغيّر حجمها أثناء عمل التطبيق.

Device matrix: food delivery app (illustrative data, last 90 days)

ID  Device                         OS                   Runs on      Tier
D1  Android mid-range, maker A     newest Android       real device  1
D2  iPhone, standard size          newest iOS           real device  1
D3  Android budget, maker B, 3 GB  Android 10 (oldest)  real device  1
D4  iPhone, smallest (375 pt)      iOS 17 (oldest)      device farm  2
D5  Android foldable               newest Android       device farm  2

Tier 1: critical journeys + regression set, every release
Tier 2: smoke set of critical journeys, every release
Tier 3: other models above 1% of sessions, before major releases
Settings: language × orientation × font size × theme, pairwise across D1..D5

جرّبها: مولّد الاختبار الزوجي (Pairwise)

أسئلة شائعة

المراجع

• Certified Tester Mobile Application Testing (CT-MAT)ISTQB · 2019منهج ISTQB التخصصي لاختبار تطبيقات الجوال: أنواع التطبيقات وتحديات الأجهزة والمنصات وأنواع الاختبار والأدوات.
• Core app quality guidelinesAndroid Developers (Google)معايير Google الأساسية لجودة تطبيقات Android — التجربة المرئية والوظائف والأداء والخصوصية والأمان — مع الاختبارات المستخدمة للتحقق منها.
• Web Content Accessibility Guidelines (WCAG) 2.2W3C · 2024توصية W3C التي تحدد معايير النجاح القابلة للاختبار لإتاحة محتوى الويب، مرتّبةً تحت أربعة مبادئ وثلاثة مستويات مطابقة (A وAA وAAA).
• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.