Internal Testing: ماهیت، نحوه عملکرد و تنظیم ترک

Internal Testing چیست؟

Internal Testing یک ترک آزمایشی در Google Play Console و TestFlight است که برای توزیع بیلدها میان اعضای تیم توسعه طراحی شده است. بر خلاف تست بتای باز، دسترسی به Internal Testing به فهرستی از آدرس‌های ایمیل تأیید شده توسط صاحب حساب توسعه‌دهنده محدود می‌شود.

مزیت اصلی — حداقل زمان تحویل بیلد به تسترها است. در Google Play، Internal Testing نیازی به تأییدیه ندارد — بیلد طی 5–15 دقیقه پس از بارگذاری در دسترس شرکت‌کنندگان قرار می‌گیرد. در App Store از طریق TestFlight، بیلد نیز بدون بررسی قبلی App تحویل داده می‌شود، اما تحت بررسی خودکار برای الزامات اولیه امنیتی قرار می‌گیرد.

تفاوت Internal Testing با سایر ترک‌ها

در Google Play سه ترک آزمایشی وجود دارد: Internal Testing، Closed Beta (Open Beta) و Production. Internal Testing سریع‌ترین و محدودترین از نظر تعداد شرکت‌کنندگان است (تا 100 نفر). Closed Beta تا 10 000 شرکت‌کننده را مجاز می‌داند و نیاز به تنظیم صفحه آزمایشی دارد. Production مرحله نهایی با تأییدیه کامل است.

چه زمانی از Internal Testing استفاده کنیم

Internal Testing برای بررسی اولیه بیلدها قبل از انتقال به ترک‌های بتا استفاده می‌شود. توسعه‌دهندگان ساخت‌های روزانه را برای تیم QA بارگذاری می‌کنند، یکپارچه‌سازی 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 دقیقه پردازش، بیلد در دسترس تسترها قرار می‌گیرد. وضعیت در کنسول قابل پیگیری است: Draft، In Review، Ready to Test.

// 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

در اکوسیستم اپل، نقش Internal Testing را TestFlight ایفا می‌کند — پلتفرمی برای توزیع نسخه‌های بتا. TestFlight تا 100 تستر داخلی را پشتیبانی می‌کند که از طریق ایمیل در App Store Connect اضافه می‌شوند. برای انتشار بیلد نیازی به گذراندن بررسی کامل App نیست، اما بیلد به طور خودکار برای حداقل الزامات بررسی می‌شود.

ویژگی‌های TestFlight Internal Testing

بر خلاف Google Play که Internal Testing اصلاً نیازی به تأییدیه ندارد، اپل بررسی اولیه خودکار انجام می‌دهد. بررسی 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 می‌تواند پس از هر بار عبور موفق از تست‌های واحد و تست‌های UI، بیلدها را در ترک Internal بارگذاری کند.

تنظیم حساب‌های آزمایشی

برای اپلیکیشن‌های دارای احراز هویت، لازم است حساب‌های آزمایشی آماده کرده و به تیم QA تحویل دهید. حساب‌ها باید به محیط آزمایشی (staging/development) دسترسی داشته باشند و روی داده‌های تولیدی تأثیر نگذارند. توصیه می‌شود یک پیکربندی جداگانه Firebase برای ترک Internal ایجاد کنید.

گردش کار QA با Internal Testing

Internal Testing پس از گذراندن بررسی‌های خودکار در CI در خط لوله QA تعبیه می‌شود. توسعه‌دهنده یا مهندس DevOps بیلد را در ترک Internal بارگذاری می‌کند، پس از آن مهندسان QA اعلان دریافت می‌کنند و به‌روزرسانی را روی دستگاه‌های آزمایشی از طریق فروشگاه اپلیکیشن نصب می‌کنند.

فراوانی بهینه انتشار

توصیه می‌شود بیلدها را روزانه یا پس از هر تغییر قابل توجه در پایگاه کد در Internal Testing منتشر کنید. تیم QA سناریوهای بحرانی را آزمایش می‌کند: احراز هویت، جریان اصلی کاربر، یکپارچه‌سازی با API و کار با ذخیره‌سازی محلی. تست رگرسیون در هر سومین یا چهارمین بیلد انجام می‌شود.

ابزارهای جمع‌آوری بازخورد

برای جمع‌آوری گزارش‌های اشکال از یکپارچه‌سازی با سیستم‌های رهگیری استفاده کنید: Jira، YouTrack، Trello یا GitHub Issues. تسترها اسکرین‌شات‌ها، لاگ‌ها و مراحل بازتولید را ارسال می‌کنند. TestFlight به طور داخلی از جمع‌آوری اسکرین‌شات‌ها و لاگ‌ها هنگام تکان دادن دستگاه پشتیبانی می‌کند — داده‌ها از طریق App Store Connect به توسعه‌دهنده ارسال می‌شوند.

یکپارچه‌سازی با خط لوله CI/CD

برای انتشار خودکار بیلدها در ترک Internal Testing، خط لوله CI/CD را پیکربندی کنید. پس از گذراندن تست‌های واحد و تست‌های UI، اسکریپت بیلد را در ترک Internal بارگذاری کرده و به تیم QA اعلان می‌فرستد. Fastlane اکشن آماده upload_to_play_store با پارامتر track: internal را تقدیم می‌دهد. برای iOS از Fastlane Pilot برای بارگذاری در TestFlight استفاده کنید.

محدودیت‌های Internal Testing

Internal Testing محدودیت‌های سختی از نظر تعداد شرکت‌کنندگان دارد: تا 100 نفر در Google Play و تا 100 تستر داخلی در TestFlight. Google Play همچنین تعداد گروه‌ها را محدود می‌کند — حداکثر 1 گروه برای ترک Internal. App Store تعداد بیلدها را محدود نمی‌کند، اما مدت اعتبار هر بیلد 90 روز است.

تفاوت محدودیت‌ها بین پلتفرم‌ها

Google Play تعداد بیلدهای بارگذاری شده در ترک Internal را محدود نمی‌کند، اما پس از 90 روز بی‌فعالیت، ترک ممکن است به طور خودکار معلق شود. TestFlight محدودیت‌های سخت‌تری دارد: تا 30 بیلد فعال همزمان، تا 10 000 تستر خارجی (نه Internal). برای رفع محدودیت‌ها، شرکت در برنامه Apple Developer Enterprise الزامی است.

مهاجرت از Internal به Beta باز

پس از پایدار شدن بیلد در ترک Internal، به Beta بسته یا باز برای آزمایش روی مخاطبان خارجی منتقل می‌شود. Google Play امکان کپی کردن تنظیمات ترک و انتقال بیلد بدون بارگذاری مجدد را فراهم می‌کند. TestFlight نیاز به ایجاد یک ترک خارجی جداگانه با افزودن گروه‌های جدید تستر دارد.

امنیت ترک Internal Testing

بیلدها در ترک Internal از دسترس خارجی محافظت می‌شوند: فقط شرکت‌کنندگان مجاز از طریق Google Play Console یا App Store Connect می‌توانند اپلیکیشن را دانلود کنند. حتی با دانستن لینک اپلیکیشن، یک کاربر خارجی نمی‌تواند بیلد را نصب کند. این امر محرمانگی ویژگی‌های جدید و حفاظت از مالکیت فکری را در مرحله توسعه تضمین می‌کند.