كل تطبيق تُسلِّمه Arekan يمرّ بعملية اختبار مُهيكَلة متعدّدة الطبقات قبل أن يصل إلى مستخدميك. يتعامل فريقنا مع الاختبار لا كمرحلة واحدة بل كانضباط يسير بالتوازي مع التطوير، من أول مكوّن إلى آخر نشر. يوثّق هذا الدليل بالضبط كيف نختبر تطبيقات الويب والجوال المُنشأة حديثاً، وما الأدوات وأطر العمل التي نستخدمها، وخطوات التأكيد المحدّدة التي نشترطها قبل أي إطلاق.
لماذا لا يمكن تخطّي مراحل الاختبار
أغلى الأخطاء هي تلك التي يكتشفها مستخدموك، لا فريقك. رأينا هذا في مشاريع العملاء: خطأ بعد الإطلاق في تدفّق دفع أو نظام مصادقة أو خط معالجة بيانات يكلّف إصلاحه أضعافاً مضاعفة مقارنةً بخطأ يُكتشَف أثناء التطوير. عملية الاختبار لدينا موجودة لاصطياد المشكلات في أرخص نقطة ممكنة — قبل أن يراها المستخدمون.
مُضاعِف تكلفة اكتشاف الخطأ: خطأ يُكتشَف في التطوير يكلّف 1x لإصلاحه. في الـ staging يكلّف 6x. في الإنتاج يكلّف 15–100x — مع الاستجابة للحوادث، واستعادة البيانات، والتواصل مع العملاء، والضرر السمعي.
منع التراجع: مع نموّ التطبيقات، يُعطّل الكود الجديد وظائف قديمة. مجموعات الاختبار المؤتمتة تلتقط التراجعات قبل الشحن وتُلغي صنف حوادث "كسرنا شيئاً لم نلمسه" في الإنتاج.
ثقة العميل: مجموعة اختبارات بتغطية موثّقة تمنح العميل دليلاً موضوعياً على الجودة — لا مجرد تأكيد لفظي بأن "الأمور تعمل".
متطلّبات الامتثال: العملاء المؤسسيون في قطاعات المالية والرعاية الصحية والحكومة كثيراً ما يشترطون دليلاً قابلاً للعرض على الاختبار ضمن عملية تأهيل المورّدين.
سرعة الانضمام: قاعدة كود مُختبَرة جيداً تُدخِل المطوّرين الجدد بسرعة أكبر بكثير — تعمل الاختبارات كتوثيق حيّ لكيفية سلوك النظام المتوقّعة.
الطبقات الخمس لاختبار تطبيقات الويب
تتطلّب تطبيقات الويب اختباراً عبر طبقات متعدّدة، وكل طبقة تلتقط صنفاً مختلفاً من المشكلات. تخطّي أي طبقة يترك فئة من الأخطاء غير مُكتشَفة حتى الإنتاج. ما نُشغّله على كل تطبيق ويب نُسلّمه:
اختبارات الوحدة: تُختبَر الدوال الفردية والمرافق ومكوّنات منطق الأعمال بمعزل. نستهدف تغطية فروع تتجاوز 80% للكود الحرج تجارياً (معالجة الدفع، المصادقة، تحويل البيانات). المكدّس: Vitest لـ Vue/Nuxt، Jest لـ Node.js، pytest لـ Python.
اختبارات التكامل: تتحقّق من عمل عدة مكوّنات معاً بشكل صحيح — مسارات API مع استعلامات قاعدة البيانات، middleware المصادقة مع حرّاس المسارات، تكاملات خدمات الطرف الثالث. تلتقط هذه أخطاء الربط التي تُفلت من اختبارات الوحدة.
اختبارات End-to-end (E2E): تُحاكي رحلات مستخدم حقيقية عبر المتصفّح — تسجيل دخول، تنقّل، إرسال نماذج، تدفّقات شراء، حالات الخطأ. المكدّس: Playwright مع مقارنة لقطات شاشة آلية. نُغطّي 5–10 رحلات مستخدم حرجة لكل تطبيق.
اختبارات الحمل والأداء: تُحاكي مستخدمين متزامنين للتحقّق من تحمّل التطبيق لحركة بمستوى الإنتاج. نستخدم k6 لنمذجة أنماط استخدام واقعية. كل endpoint مُحلَّل؛ الاستعلامات البطيئة (>200ms) تُعلَّم قبل الإطلاق.
الفحص الأمني: فحص OWASP Top 10 مؤتمت عبر OWASP ZAP مدمج في خط CI، إضافة إلى مراجعة يدوية لمنطق المصادقة والتفويض والتحقق من البيانات. يوقّع فريق الأمن لدينا على أي تطبيق يتعامل مع بيانات حسّاسة.
اختبارات خاصة بالجوال: ما المختلف ولماذا يهم
تواجه تطبيقات الجوال تحدياً مختلفاً جذرياً عن الويب. تجزّؤ الأجهزة وتنوع إصدارات نظام التشغيل وتقلّب الشبكات وقيود العتاد تخلق أنماط فشل غير موجودة في التطبيقات المعتمدة على المتصفّح. إليكم طبقة الاختبار الخاصة بالجوال لدينا، المستنِدة إلى مشاريع عبر الشرق الأوسط وتركيا:
اختبار مصفوفة الأجهزة: نختبر على مصفوفة محدّدة من أجهزة فعلية حقيقية — لا محاكيات فحسب — تغطّي أعلى 80% من أنواع الأجهزة الفعلية في السوق المستهدف. لعملاء الشرق الأوسط هذا يعني iPhones الحالية وما قبلها بجيلين، Samsung Galaxy (سلسلتي S وA)، وأجهزة Xiaomi التي تهيمن على السوق.
تغطية إصدارات نظام التشغيل: نختبر على iOS 16 و17 و18 وعلى Android 12 و13 و14 و15. أكثر انهيارات الإنتاج شيوعاً التي نراها تسبّبها تغييرات API خاصة بالنظام تظهر فقط على إصدارات أقدم لا تزال شائعة الاستخدام.
محاكاة ظروف الشبكة: نختبر تحت ظروف 4G و3G وWiFi ضعيف باستخدام تقييد الشبكة. التطبيقات التي تعمل على الاتصالات السريعة كثيراً ما تنكسر على البطيئة — انتهاء المهلات، غياب حالات التحميل، ومنطق إعادة المحاولة المعطوب هي أكثر الاكتشافات شيوعاً.
اختبار الأذونات ودورة الحياة: يجب على تطبيقات الجوال أن تتعامل مع رفض الأذونات (كاميرا، موقع، إشعارات)، وانتقالات الخلفية والمقدمة، وظروف الذاكرة المنخفضة، والمقاطعات (مكالمات، إشعارات). نختبر كل هذه الانتقالات صراحةً.
التحقّق من تكامل الإبلاغ عن الأعطال: قبل أي إصدار جوال نتحقّق من أن Sentry أو Firebase Crashlytics متكامل بشكل صحيح ويُبلّغ عن الأعطال إلى المشروع الصحيح — حتى إذا حدث خطأ ما بعد الإطلاق يكون مرئياً فوراً.
الفحص المسبق لامتثال متجر التطبيقات: نُجري فحوصات إرشادات Apple App Store وGoogle Play Store قبل التقديم، بما فيها متطلبات بيان الخصوصية وتبريرات الأذونات وإعلانات التصنيف العمري — لتجنّب دورة رفض المراجعة متعدّدة الأيام التي تُفاجئ الفرق.
قائمة فحص تأكيد الإطلاق
قبل تسليم أي تطبيق للعميل أو نشره في الإنتاج، يُشغّل فريقنا قائمة فحص إطلاق مُهيكَلة. هذه هي البوابة الأخيرة قبل الإطلاق. كل ما في هذه القائمة يجب أن ينجح — لا استثناءات لضغط المواعيد النهائية.
كل مجموعات الاختبار المؤتمتة تنجح على build الإنتاج (لا فقط build التطوير): اختلافات البيئة بين dev والإنتاج تسبّبت في فشل إطلاقات لمشاريع "نجحت كل اختباراتها محلياً".
مراقبة الأخطاء فعّالة ومتحقَّق منها: نُطلق خطأ اختبار متعمّداً ونؤكّد ظهوره في Sentry أو Crashlytics خلال 60 ثانية قبل الإطلاق.
خط الأداء الأساسي موثَّق: أزمنة تحميل الصفحات (ويب)، زمن إطلاق التطبيق (جوال)، وأزمنة استجابة الـ APIs الحرجة مُسجَّلة. هذا الخط الأساسي يُتيح كشف التراجع بسرعة بعد الإطلاق.
النسخ الاحتياطية وخطة التراجع مؤكَّدة: لتطبيقات الويب نؤكّد أن خط النشر يدعم التراجع إلى الإصدار السابق بأمر واحد. للجوال، يُحتفَظ بالبناء السابق في متجر التطبيقات للتراجع الطارئ.
جلسة عرض للعميل مكتملة: جلسة مشاركة شاشة يختبر فيها العميل التطبيق بنفسه في بيئة staging. هذه ليست اختيارية — تلتقط فجوات التوقّعات التي لا يستطيع أي اختبار تقني العثور عليها.
التحقّق من تطابق Staging والإنتاج: مخطط قاعدة البيانات، متغيرات البيئة، أعلام الميزات، ومفاتيح APIs الطرف الثالث، كلها تُؤكَّد صحّتها لبيئة الإنتاج قبل التحويل.
