Internal Testing: ما هو، وكيف يعمل، وكيفية إعداد المسار

ما هو Internal Testing؟

Internal Testing هو مسار اختبار في Google Play Console و TestFlight مصمم لتوزيع الإصدارات بين أعضاء فريق التطوير. على عكس اختبار بيتا المفتوح، فإن الوصول إلى Internal Testing مقصور على قائمة عناوين البريد الإلكتروني المعتمدة من قبل مالك حساب المطور.

الميزة الرئيسية هي أقل وقت توصيل للإصدار إلى المختبرين. في Google Play، لا يتطلب Internal Testing المرور عبر المراجعة — يظهر الإصدار للمشاركين خلال 5–15 دقيقة بعد التحميل. في App Store عبر TestFlight، يتم أيضًا توصيل الإصدار دون مراجعة مسبقة للتطبيق، ولكنه يخضع للتحقق التلقائي من متطلبات الأمان الأساسية.

كيف يختلف Internal Testing عن المسارات الأخرى

يوجد في Google Play ثلاثة مسارات اختبار: Internal Testing و Closed Beta (Open Beta) والإنتاج. Internal Testing هو الأسرع والأكثر تقييدًا من حيث عدد المشاركين (حتى 100 شخص). يسمح Closed Beta بما يصل إلى 10,000 مشارك ويتطلب إعداد صفحة اختبار. الإنتاج هو المرحلة النهائية مع مراجعة كاملة.

متى تستخدم Internal Testing

يُستخدم Internal Testing للتحقق الأولي من الإصدارات قبل نقلها إلى مسارات بيتا. يقوم المطورون بتحميل إصدارات يومية لفريق ضمان الجودة، والتحقق من تكامل SDK الجديد، واختبار التوافق مع إصدارات مختلفة من نظام التشغيل، واكتشاف أخطاء الانحدار قبل أن يرى الإصدار مختبرين خارجيين.

Internal Testing في Google Play

في Google Play Console، Internal Testing هو مسار منفصل متاح في قسم Release → Testing. لإضافة مختبر، يكفي إدخال عنوان بريده الإلكتروني — يتلقى المشارك دعوة ورابطًا للانضمام عبر Google Play. يتم تحميل الإصدارات من خلال نفس واجهة إصدارات الإنتاج.

عملية النشر في المسار الداخلي

يقوم المطور بتحميل App Bundle أو APK في قسم Internal Testing في Google Play Console. يتحقق النظام من المتطلبات الأساسية: التوقيع وإصدار الكود والتوافق مع API. بعد 5–15 دقيقة من المعالجة، يصبح الإصدار متاحًا للمختبرين. يتم تتبع الحالة في لوحة التحكم: مسودة، قيد المراجعة، جاهز للاختبار.

// Fastlane — النشر في مسار Internal Testing
lane :internal_testing do
    gradle(task: ":app:assembleRelease")
    
    upload_to_play_store(
        track: "internal",
        release_status: "completed",
        rollout: 1.0
    )
    
    slack(
        message: "Build uploaded to Internal Testing"
    )
end

إدارة المختبرين

تتم إضافة المشاركين من خلال قسم Testers في Google Play Console. يتم دعم التحميل الجماعي عبر ملف CSV. يتلقى كل مختبر بريدًا إلكترونيًا مع دعوة وتعليمات التثبيت. لإلغاء الوصول، يكفي إزالة المشارك من المجموعة — يستمر التطبيق المثبت في العمل، ولكن لا تصل تحديثات جديدة.

Internal Testing في App Store عبر TestFlight

في نظام Apple البيئي، يقوم TestFlight بدور Internal Testing — وهي منصة لتوزيع الإصدارات التجريبية. يدعم TestFlight ما يصل إلى 100 مختبر داخلي، يتم إضافتهم عبر البريد الإلكتروني من خلال App Store Connect. لا يتطلب نشر الإصدار مراجعة كاملة للتطبيق، ولكن يتم التحقق من الإصدار تلقائيًا للامتثال للمتطلبات الدنيا.

ميزات TestFlight Internal Testing

على عكس Google Play، حيث لا يتطلب Internal Testing أي مراجعة، يقوم Apple بإجراء مراجعة أساسية تلقائية. يستغرق التحقق من 30 إلى 60 دقيقة ويتضمن فحص الكود الثنائي بحثًا عن API ضارة والامتثال للمتطلبات الأساسية. بعد التحقق الناجح، يكون الإصدار متاحًا للمختبرين في غضون 24 ساعة. الإصدار صالح لمدة 90 يومًا.

إعداد Internal Testing في App Store Connect

في App Store Connect، يتم تكوين Internal Testing في قسم TestFlight → Internal Testing. يضيف مالك الحساب المختبرين عبر البريد الإلكتروني ويعين الأدوار. بعد تحميل الإصدار عبر Xcode أو Transporter، يقوم النظام بإخطار المشاركين بتوفر إصدار جديد. يقوم المختبرون بتثبيت التطبيق عبر تطبيق TestFlight على أجهزتهم.

كيفية إعداد مسار Internal Testing

يستغرق إعداد Internal Testing لكلا النظامين من 10 إلى 30 دقيقة. فيما يلي إرشادات خطوة بخطوة لـ Google Play و App Store. لا تتطلب العملية تغييرات في كود التطبيق — يكفي إعداد لمرة واحدة لوحدة تحكم المطور.

التكامل مع أنظمة CI/CD

يدعم كلا المتجرين النشر في Internal Testing عبر API. للأتمتة، يتم استخدام Gradle Play Publisher (Google Play) و Fastlane(كلا النظامين). يمكن لخط أنابيب CI/CD تحميل الإصدارات إلى المسار الداخلي بعد كل تشغيل ناجح لاختبارات الوحدة واختبارات واجهة المستخدم.

إعداد حسابات الاختبار

للتطبيقات التي تتطلب مصادقة، من الضروري إعداد حسابات اختبار وتسليمها لفريق ضمان الجودة. يجب أن تتمتع الحسابات بإمكانية الوصول إلى بيئة الاختبار (staging/development) وألا تؤثر على بيانات الإنتاج. يُوصى بإنشاء تكوين Firebase اختبار منفصل للمسار الداخلي.

سير عمل ضمان الجودة مع Internal Testing

يتم دمج Internal Testing في خط أنابيب ضمان الجودة بعد اجتياز الفحوصات التلقائية في CI. يقوم المطور أو مهندس DevOps بتحميل الإصدار إلى المسار الداخلي، وبعد ذلك يتلقى مهندسو ضمان الجودة إخطارًا ويقومون بتثبيت التحديث على أجهزة الاختبار عبر متجر التطبيقات.

التكرار الأمثل للنشر

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

أدوات جمع الملاحظات

لجمع تقارير الأخطاء، استخدم التكامل مع أنظمة التتبع: Jira أو YouTrack أو Trello أو GitHub Issues. يرسل المختبرون لقطات شاشة وسجلات وخطوات إعادة الإنتاج. يدعم TestFlight بشكل مدمج جمع لقطات الشاشة وسجلات الجهاز عند الهز — يتم إرسال البيانات إلى المطور عبر App Store Connect.

التكامل مع خط أنابيب CI/CD

لنشر الإصدارات تلقائيًا في مسار Internal Testing، قم بإعداد خط أنابيب CI/CD. بعد اجتياز اختبارات الوحدة واختبارات واجهة المستخدم، يقوم البرنامج النصي بتحميل الإصدار إلى المسار الداخلي وإرسال إخطار لفريق ضمان الجودة. يوفر Fastlane الإجراء الجاهز upload_to_play_store مع المعلمة track: internal. لنظام iOS، استخدم Fastlane Pilot للتحميل إلى TestFlight.

قيود وحدود Internal Testing

Internal Testing له حدود صارمة على عدد المشاركين: حتى 100 شخص في Google Play وحتى 100 مختبر داخلي في TestFlight. يحد Google Play أيضًا من عدد المجموعات — مجموعة واحدة كحد أقصى للمسار الداخلي. لا يحد App Store من عدد الإصدارات، لكن كل إصدار صالح لمدة 90 يومًا.

اختلافات الحدود بين المنصات

لا يحد Google Play من عدد الإصدارات المرفوعة في المسار الداخلي، ولكن بعد 90 يومًا من عدم النشاط، قد يتم تعليق المسار تلقائيًا. TestFlight له حدود أكثر صرامة: حتى 30 إصدارًا نشطًا في وقت واحد، وحتى 10,000 مختبر خارجي (وليس داخلي). لإزالة القيود، يلزم المشاركة في برنامج Apple Developer Enterprise.

الترحيل من داخلي إلى بيتا المفتوحة

بعد استقرار الإصدار في المسار الداخلي، يتم نقله إلى Closed أو Open Beta للاختبار مع جمهور خارجي. يسمح Google Play بنسخ إعدادات المسار ونقل الإصدار دون إعادة تحميل. يتطلب TestFlight إنشاء مسار خارجي منفصل مع مجموعات مختبرين جديدة.

أمان مسار Internal Testing

الإصدارات في المسار الداخلي محمية من الوصول الخارجي: يمكن فقط للمشاركين المصرح لهم عبر Google Play Console أو App Store Connect تنزيل التطبيق. حتى إذا كان شخص ما يعرف رابط التطبيق، فلن يتمكن المستخدم غير المصرح له من تثبيت الإصدار. يضمن ذلك سرية الميزات الجديدة ويحمي الملكية الفكرية خلال مرحلة التطوير.