Google Play Kapalı Test Şartı: 12 Test Kullanıcısı ve 14 Gün Nasıl Geçilir?

Bu sayfaya büyük ihtimalle "Üretim erişimine başvur" düğmesinin gri kaldığını ya da başvurunuzun "daha fazla test gerekiyor" benzeri bir yanıtla döndüğünü gördükten sonra geldiniz. Panik yapmanıza gerek yok. Kural net, süreç öngörülebilir ve doğru planlarsanız tek seferde geçebilirsiniz. Önce şu adımlarla başlayın:

1. Play Console'da uygulamanızın kapalı test kanalında yayında bir sürüm olup olmadığını kontrol edin.
2. Test listesinde kaç kişinin gerçekten katıldığını (opt-in, yani teste katılma onayı) sayın; listeye eklenmek katılmak demek değildir.
3. En az 12 kişinin aynı anda ve 14 gün boyunca kesintisiz katılımda kalacağı bir takvim kurun.
4. Testçilerden uygulamayı her gün açmalarını ve geri bildirim vermelerini isteyin.
5. Süre dolunca başvuru formunu hazırladığınız notlarla doldurun.

Bu yazıda Talha Aslan ve ekibi olarak bu süreci uçtan uca anlatıyoruz. Kuralların ayrıntısını Play Console Yardım'daki yeni kişisel hesaplar için test şartları sayfasından doğruladık. Ancak Google eşikleri zaman zaman güncelleyebilir; bu nedenle güncel değeri her zaman resmi sayfadan kontrol edin.

Bu şart hangi geliştirici hesaplarını kapsıyor?

Resmi yardım sayfası kuralı açıkça kişisel geliştirici hesapları için tanımlıyor. Google'ın belirlediği bir tarihten sonra açılan kişisel hesaplar, üretim kanalına çıkmadan önce bu kapalı test aşamasını tamamlamak zorunda. Daha eski kişisel hesaplar ise bu yeni kuralın hedefi değil. Hesabınızın hangi gruba girdiğini Play Console panosu size zaten gösterir; üretim ile ön kayıt özellikleri kilitliyse siz de şartın kapsamındasınız.

Kuruluş hesapları farklı bir yoldan ilerler. Google, hesap türü seçimini anlatan yardım sayfasında kuruluş hesabı açarken D-U-N-S numarası istediğini belirtiyor. Yani işletmeler kimliklerini şirket kaydı üzerinden doğrular. Kapalı test şartının metni ise kişisel hesapları hedef alıyor.

Öte yandan şunu unutmayın: hesap türü bir tercih değil, gerçeği yansıtması gereken bir beyandır. Bireysel bir geliştiriciyseniz yalnızca testten kaçmak için kuruluş hesabı açmaya çalışmak doğru bir yol değildir. Bu konuya aşağıda ayrıca değiniyoruz.

12 test kullanıcısı ve 14 gün kuralı tam olarak ne anlama geliyor?

Kuralın en çok yanlış anlaşılan kısmı sayım biçimidir. Resmi metne göre başvuru anında en az 12 testçinin kapalı teste katılım onayı vermiş olması ve önceki 14 gün boyunca kesintisiz katılımda kalması gerekiyor. Dolayısıyla toplamda 30 kişinin bir ara teste girmiş olması yetmez; aynı 12 kişinin süre boyunca listede kalması gerekir.

• Katılım kesintisiz olmalı: Bir testçi testten çıkıp sonra geri dönerse, onun için 14 gün yeniden başlar.
• Erken ayrılan hesaba girmez: 14 günü doldurmadan testten ayrılan kişi hesaba katılmaz.
• Liste ile katılım farklıdır: E-posta listesine eklemek yetmez; kişi davet bağlantısından teste katılmayı onaylamalıdır.
• Etkileşim de önemlidir: Google, başvurunun reddedilme nedenleri arasında yetersiz testçi etkileşimini de sayıyor.

Bu nedenle biz projelerimizde hedefi 12 değil, 15 ile 20 arasında tutuyoruz. Bu bir kural değil, saha tecrübesine dayalı bir güvenlik payı. Birkaç kişinin telefon değiştirmesi ya da testten çıkması bütün takvimi baştan başlatmasın diye yedek testçi bulundurmak işinizi kolaylaştırır.

Dahili test, kapalı test ve açık test arasındaki fark nedir?

Play Console'da üç test kanalı var ve şart yalnızca birini sayar. Karışıklığın büyük kısmı şuradan doğuyor: geliştiriciler dahili testte 14 gün geçirip bunun yeterli olduğunu düşünüyor. Aşağıdaki tablo farkları özetliyor:

Resmi sayfa, dahili testin herhangi bir erişim şartı olmadığını, kapalı testin ise uygulama kurulumunun tamamlanmasını beklediğini söylüyor. Açık test ise ancak üretim erişimi verildikten sonra kullanılabiliyor. Kısacası sayacı başlatan tek yer kapalı test kanalıdır.

Google Play kapalı test kanalını adım adım nasıl kurarsınız?

Kurulum birkaç saat sürer, ama sırayı doğru izlemezseniz günler kaybedebilirsiniz. Çünkü davet bağlantısını ancak sürüm yayına girdikten sonra görürsünüz. Biz şu sırayı izliyoruz:

1. Uygulama panosundaki kurulum görevlerini bitirin: gizlilik politikası, uygulama erişimi, içerik derecelendirmesi, hedef kitle ve veri güvenliği bölümleri.
2. Mağaza girişini hazırlayın: uygulama adı, kısa ve uzun açıklama, simge, ekran görüntüleri.
3. Kapalı test kanalını açın ve test kullanıcılarını e-posta listesi ya da Google Grubu ile ekleyin.
4. İmzalı uygulama paketini (AAB) yükleyin, sürüm notlarını yazın ve sürümü incelemeye gönderin.
5. Sürüm yayınlandıktan sonra görünen katılım bağlantısını testçilere iletin.
6. Her testçinin bağlantıdan katılım onayı verdiğini ve uygulamayı Google Play'den indirdiğini doğrulayın.

Test kanallarını anlatan resmi yardım sayfası, uygulama durumu yayında olmadan katılım bağlantısının ortaya çıkmadığını ve ilk yayından sonra bağlantının etkinleşmesinin birkaç saat sürebileceğini belirtiyor. Ayrıca her testçinin bir Google hesabıyla katılması gerekiyor. Testçinin cihazında farklı bir Google hesabı açıksa, katılım onayını verdiği hesapla Play Store'a girdiğinden emin olun.

Test kullanıcılarını nereden bulabilirsiniz?

Resmi başvuru formu, testçi bulmanın ne kadar kolay olduğunu doğrudan soruyor. Demek ki Google bunun bir zorluk olduğunun farkında. İyi haber şu: 12 gerçek kişi bulmak, çoğu işletme için sandığından kolaydır. Örneğin şu kaynakları düşünebilirsiniz:

• Çalışanlarınız ve iş ortaklarınız; özellikle uygulamanın hedef kitlesine benzeyenler.
• Mevcut müşterileriniz; sadık müşterilere "ilk deneyen siz olun" daveti çoğu zaman olumlu karşılık bulur.
• Sosyal medya takipçileriniz ve e-posta bülteni aboneleriniz.
• Sektörünüzdeki meslek grupları ve topluluklar.
• Aile ve arkadaş çevreniz; ancak yalnızca bu gruba dayanmak geri bildirimin kalitesini düşürür.

Örnek senaryo: Bir kuaför randevu uygulaması geliştirdiğinizi düşünün. Salonun düzenli müşterilerinden on kişi, iki çalışan ve iki tedarikçi temsilcisi size 14 kişilik doğal bir test grubu verir. Üstelik bu kişiler uygulamayı gerçek ihtiyaçla kullanır, bu da başvuru formundaki "kullanım beklenen üretim davranışına benzedi mi" sorusuna somut cevap üretir.

Uygulama fikriniz henüz şekilleniyorsa, mobil uygulama geliştirme hizmetimizde test grubunu da projenin parçası olarak planlıyoruz; uygulamanızı biz geliştirir, kapalı testi yönetir ve mağazaya biz çıkarırız.

Testçi değiş tokuş grupları ve ücretli testçi hizmetleri güvenli mi?

İnternette "sen benimkini test et, ben seninkini" mantığıyla çalışan gruplar ve para karşılığı testçi sağladığını söyleyen hizmetler var. Bunların hepsini aynı kefeye koymak doğru olmaz, fakat riskleri açıkça bilmeniz gerekir.

Birincisi, bu kişiler uygulamanızın hedef kitlesi değildir. Uygulamayı bir kez açıp bırakırlar; böylece etkileşim zayıf kalır ve Google'ın saydığı "yetersiz testçi etkileşimi" nedenine doğrudan düşersiniz. İkincisi, başvuru formunda testçi geri bildirimini ve bunu nasıl topladığınızı anlatmanız gerekir. Gerçek geri bildirim yoksa dürüst bir cevap da yazamazsınız.

Üçüncüsü ve en önemlisi: sahte hesaplar, toplu halde açtığınız Google hesapları ya da emülatörlerde döndürdüğünüz yapay katılımı Google, sistemlerini atlatma girişimi olarak görür. Bu yol yalnızca başvurunuzu değil, geliştirici hesabınızı da riske atar. Biz bu yöntemleri hiçbir koşulda önermiyoruz. Değiş tokuş grubuna katılacaksanız bile bunu ana kaynak değil, gerçek testçilerinize eklenen küçük bir tamamlayıcı olarak görün.

Testçiler 14 gün boyunca ne yapmalı?

Katılım tek başına yetmez; Google testin gerçekten yapıldığını görmek ister. Başvuru formu, testçilerin uygulamadaki tüm özellikleri kullanıp kullanmadığını soruyor. O yüzden testçilere belirsiz bir "deneyin bakalım" mesajı yerine net bir görev listesi verin.

Örneğin ilk gün kayıt ve giriş akışını, ikinci gün ana özelliği, üçüncü gün bildirim ve ayarları denemelerini isteyebilirsiniz. Ardından ikinci haftada "uygulamayı normal hayatınızda kullanın" dönemine geçin. Böylece hem özellik kapsamını hem de gerçek kullanım davranışını aynı test içinde görürsünüz.

• Uygulamayı en az birkaç günde bir açmak.
• Her ana ekranı ve akışı en az bir kez denemek.
• Çökme, donma veya yanlış metin gördüğünde ekran görüntüsüyle bildirmek.
• Test süresi bitmeden testten çıkmamak ve uygulamayı kaldırmamak.

Son madde kritik. Bir testçinin "ben denedim, sildim" demesi sizin için sorun değildir, ama katılım onayını geri çekmesi sayacı onun için sıfırlar. Bu yüzden testçilere ilk mesajda bunu açıkça yazın.

Testçilere ilk mesajda ne yazmalısınız?

Testçilerin çoğu bu süreci ilk kez yaşar. Bu yüzden ilk mesajınız ne kadar açık olursa, 14 gün boyunca o kadar az soru ve o kadar az kayıp yaşarsınız. Biz ilk mesajı kısa tutuyor ama şu bilgileri mutlaka ekliyoruz:

1. Uygulamanın ne işe yaradığını anlatan iki cümlelik bir özet.
2. Katılım bağlantısı ve bağlantıyı hangi Google hesabıyla açmaları gerektiği.
3. Uygulamayı Google Play'den indirme adımı; dosya olarak gönderilen kurulumlar teste dahil olmaz.
4. 14 gün boyunca testten çıkmamaları gerektiğini anlatan açık bir not.
5. Gün gün görev listesi ve geri bildirimi nereye yazacakları.

Ayrıca mesajın sonuna bir teşekkür ve küçük bir jest ekleyebilirsiniz. Örneğin yayından sonra testçilere uygulamada erken erişim rozeti ya da ilk ay ücretsiz premium gibi bir ayrıcalık sunabilirsiniz. Ancak bu ayrıcalığı olumlu yorum şartına bağlamayın; testçiler mağazaya herkese açık yorum da yazamaz. Amaç yalnızca gerçek kullanımı teşvik etmektir.

Son olarak test süresinin ortasında ve bitimine üç gün kala kısa birer hatırlatma gönderin. Böylece ilgisi azalan testçileri yeniden kazanırsınız.

Geri bildirimi nasıl toplar ve belgelersiniz?

Resmi yardım sayfası, açık ve kapalı testlerde testçilerin Google Play üzerinden size özel geri bildirim gönderebildiğini, ancak sizin de ayrıca bir geri bildirim kanalı sağlamanızı öneriyor. Ayrıca test sürümüne gelen geri bildirimler uygulamanızın herkese açık puanını etkilemez.

Pratikte en kolay yöntem tek bir yerde toplamaktır. Örneğin kısa bir form, ortak bir e-posta adresi ya da testçilere özel bir mesajlaşma grubu kurabilirsiniz. Sonra her geri bildirimi bir tabloya şu sütunlarla yazın: tarih, testçi, ekran, sorun ya da öneri, aldığınız aksiyon.

Bu tablo iki işe yarar. Birincisi, hataları önceliklendirip düzeltirsiniz. İkincisi, üretim erişimi başvurusundaki "geri bildirimi nasıl topladınız" ve "testten öğrendiklerinize göre ne değiştirdiniz" sorularına somut, kendi verinize dayanan cevaplar yazarsınız. Biz her kapalı testte en az bir düzeltme sürümünü test sırasında yayınlamayı da öneriyoruz; çünkü bu, sürecin gerçekten işlediğinin en açık kanıtıdır.

Üretim erişimi başvurusunda hangi sorular var?

14 gün dolup 12 testçi şartı sağlandığında Play Console panosunda üretim erişimine başvuru seçeneğini görürsünüz. Resmi sayfaya göre form üç bölümden oluşuyor:

1. Kapalı testiniz hakkında: Testçi bulmanın ne kadar kolay olduğu, testçilerin tüm özellikleri kullanıp kullanmadığı, kullanımın üretimde beklenen davranışa benzeyip benzemediği ve testçi geri bildiriminin özeti ile nasıl toplandığı.
2. Uygulamanız hakkında: Hedef kitle, uygulamanın kullanıcıya sağladığı değer (oyunlarda oyunu benzersiz kılan şey) ve ilk yılda beklenen yükleme aralığı.
3. Üretime hazırlığınız hakkında: Testten öğrendiklerinize göre yaptığınız değişiklikler ve uygulamanın üretime hazır olduğuna nasıl karar verdiğiniz.

Google, bu cevapların uygulamanın görünürlüğünü, Play Console özelliklerine erişimi ya da geliştirici programlarına uygunluğu etkilemediğini belirtiyor. Yine de Google bu cevapları başvuruyu değerlendirirken okuyor. Ayrıca formdan kaydetmeden çıkarsanız yazdıklarınız kaybolur; bu yüzden cevapları önce ayrı bir belgede hazırlayın.

Başvuru sorularına nasıl güçlü cevap yazarsınız?

Güçlü cevap, kısa ama somut cevaptır. Genel ifadeler yerine test sırasında gerçekten olanı anlatın. Bunu yaparken uydurma rakam vermeyin; elinizde ne varsa onu yazın.

Örnek senaryo için zayıf bir cevap şöyle olur: "Testçiler uygulamayı sevdi." Güçlü bir cevap ise şuna benzer: "Testçiler randevu oluşturma, iptal ve hatırlatma akışlarını denedi. Üç kişi takvim ekranında tarih seçiminin zor olduğunu bildirdi; ikinci sürümde seçiciyi değiştirdik. Bildirim izni isteğini ilk açılıştan randevu sonrasına taşıdık." Bu cevap hem sorunu hem çözümü hem de değişikliği gösterir.

• Hedef kitle: "Herkes" yazmayın; yaş, ihtiyaç ve bölge bazında tarif edin.
• Değer önerisi: Uygulamanın hangi sorunu çözdüğünü tek paragrafta anlatın.
• Yükleme tahmini: Gerçekçi bir aralık seçin; abartı size puan kazandırmaz.
• Hazırlık kararı: Çökme oranı, kapanan hata sayısı ve tamamlanan akışlar gibi kendi ölçütlerinizi yazın.

Google Play kapalı test neden geçersiz olur?

Resmi sayfa, üretim erişimi başvurusunun neden reddedilebileceğini ya da gecikebileceğini açıkça listeliyor. Bunları bilirseniz Google Play kapalı test sürecini tek seferde tamamlama şansınız artar:

• Politika uyumsuzluğu: Uygulama Google Play Geliştirici İçerik Politikaları ile uyumlu değilse red, inceleme gecikmesi ve daha uzun itiraz süreçleri yaşanabilir.
• Yetersiz testçi: Katılımda 12'den az testçi varsa Google sizden testi sürdürmenizi ister.
• Yetersiz etkileşim: Testçiler teste girmiş ama uygulamayı neredeyse hiç kullanmamışsa aynı sonuçla karşılaşırsınız.
• İşlev sorunları: Çökmeler, çalışmayan özellikler ya da eksik ekranlar.
• Eksik giriş bilgisi: Uygulama giriş gerektiriyorsa ve çalışan test hesabı vermediyseniz.

Saha tecrübemizde en sık görülen tablo, testçilerin ilk gün uygulamayı indirip bir daha açmamasıdır. Sayı tutar ama etkileşim tutmaz. Bu yüzden sayacı başlatmadan önce testçilere görev listesini ve hatırlatma takvimini mutlaka iletin.

Başvurunuz reddedilirse ne yapmalısınız?

Red, hesabınızın kapandığı anlamına gelmez. Çoğu durumda Google sizden testi sürdürmenizi ister. Bu durumda yapmanız gerekenler oldukça açık:

1. Google'dan gelen e-postayı ve Play Console bildirimini dikkatle okuyun; ret nedenini not edin.
2. Neden testçi sayısı ya da etkileşim ise, yeni testçi ekleyin ve mevcut testçileri yeniden harekete geçirin.
3. Neden işlev sorunu ise, ön lansman raporunu ve geri bildirim tablonuzu inceleyip düzeltme sürümü yayınlayın.
4. Sorun politika kaynaklıysa, ilgili politika başlığını okuyun ve uygulamayı düzeltmeden yeniden başvurmayın.
5. Gerekli süreyi bekledikten sonra formu güncel bilgilerle yeniden doldurun.

Resmi sayfa incelemenin genellikle yedi gün veya daha kısa sürdüğünü, ancak bazen uzayabileceğini belirtiyor. Bu süre değişebilir; güncel bilgiyi resmi sayfadan kontrol edin. Uygulamanız yayından sonra politika nedeniyle kaldırılırsa süreç farklıdır; bunun için Google Play uygulama kaldırma ve itiraz rehberimize bakabilirsiniz. Ayrıca mağaza incelemesinde sık görülen ret nedenlerini uygulamaların neden reddedildiğini anlattığımız yazıda topladık.

Giriş gerektiren uygulamalarda test hesabını nasıl verirsiniz?

Uygulamanız kullanıcı girişi istiyorsa, inceleme ekibinin içeriye girebilmesi gerekir. Aksi halde inceleyici yalnızca giriş ekranını görür ve uygulamayı değerlendiremez. Resmi sayfa, çalışan test giriş bilgilerinin eksik olmasını başvurunun gecikme nedenleri arasında sayıyor.

Uygulama panosundaki uygulama erişimi bölümünde inceleme için bir kullanıcı adı ve şifre tanımlarsınız. Bu hesabın şu özelliklere sahip olmasına dikkat edin:

• Süresi dolmayan ve şifresi değişmeyen ayrı bir inceleme hesabı olsun.
• Telefon ya da e-posta doğrulama kodu istemesin; istiyorsa bunu atlatacak talimatı açıkça yazın.
• Uygulamadaki tüm ana özelliklere erişsin; boş bir hesap yerine örnek verilerle dolu olsun.
• Bölge ya da abonelik kısıtı varsa, inceleme için bu kısıtı kaldırın.

Aynı hesabı ön lansman raporu taraması için de kullanabilirsiniz. Böylece otomatik tarama da giriş ekranında takılıp kalmaz.

Ön lansman raporu kapalı testte size nasıl yardım eder?

Ön lansman raporu, Play Console'un uygulama paketini yüklediğinizde otomatik olarak çalıştırdığı bir testtir. Google uygulamanızı test cihazlarına kurar, birkaç dakika boyunca dokunma, yazma ve kaydırma gibi temel hareketlerle uygulamada dolaşır ve sonuçları raporlar. Rapor kararlılık, Android uyumluluğu, performans ve erişilebilirlik sorunlarını kapsar.

Bu rapor kapalı test döneminde size ücretsiz bir ikinci göz sağlar. Özellikle "çökmeler ve eksik ekranlar" ret nedenine karşı erken uyarı verir. Bu yüzden her yeni test sürümünü yükledikten sonra raporu kontrol edin ve kritik bulguları testçilerin fark etmesini beklemeden düzeltin.

Ancak ön lansman raporu gerçek testçinin yerini tutmaz. Otomatik tarama akışları rastgele dolaşır; ödeme, randevu ya da sipariş gibi iş mantığı adımlarını sizin gibi düşünemez. İkisini birlikte kullanın. Web projelerinde kullandığımız mantık burada da geçerli; yayın öncesi test ve kalite kontrol listemiz mobil uygulamalar için de iyi bir başlangıç çerçevesi sunar.

Kuruluş hesabı açmak bu şartı atlatmanın yolu mu?

Bu soruyu çok sık duyuyoruz ve cevabı net: Hesap türünü gerçek durumunuza göre seçmelisiniz. Resmi yardım sayfası, kişisel hesabın kişisel kullanım için, kuruluş hesabının ise bir kuruluş veya işletme adına açıldığını söylüyor. Ayrıca finansal ürünler, sağlık uygulamaları ve bazı başka kategoriler için kuruluş hesabı zorunlu.

Gerçekten bir şirketiniz varsa, uygulamayı şirket adına yayınlamak zaten doğru tercihtir. Bunun için D-U-N-S numarası gerekir ve Google, numaranın Dun & Bradstreet üzerinden ücretsiz alındığını, üçüncü taraf hizmetlerin yüksek ücret isteyebileceğini hatırlatıyor. D-U-N-S sürecinin Apple tarafında nasıl işlediğini Apple Developer kaydı ve D-U-N-S yazımızda anlattık; mantık benzerdir.

Öte yandan şirketiniz yoksa ya da başkasının şirket bilgilerini kullanmayı düşünüyorsanız, bu yol hem doğrulamayı geçemez hem de hesabınızı riske atar. Google yanlış beyanı, sistemlerini atlatma girişimi olarak görür. Kişisel hesapla 14 günlük testi düzgün yürütmek her zaman daha güvenli ve daha hızlıdır.

Örnek senaryo: Google Play kapalı test takvimi nasıl olmalı?

Aşağıdaki takvim, bir randevu uygulaması için kurguladığımız örnek bir senaryodur. Süreler saha tecrübesine dayalı başlangıç aralığıdır, garanti değildir.

Bu takvimde dikkat etmeniz gereken nokta, sayaç ilk gün değil, testçilerin katılım onayı verdiği gün başlar. Bu nedenle katılımı ilk gün tek tek doğrulamak, takvimin tamamını korur.

Hangi uygulama altyapısı test sürecini kolaylaştırır?

Kapalı test kuralı, uygulamanın hangi teknolojiyle yazıldığına bakmaz. Native Kotlin, Flutter ya da React Native fark etmez; Google'a giden şey imzalı uygulama paketidir. Ancak altyapı seçimi, test sırasında düzeltme hızınızı doğrudan etkiler.

Örneğin tek kod tabanıyla hem Android hem iOS geliştiriyorsanız, testçilerin bildirdiği bir hatayı iki platformda birden düzeltirsiniz. Bu yaklaşımın artılarını ve eksilerini React Native rehberimizde ele aldık. Tamamen native Android geliştiriyorsanız da ekibinizin temel yetkinliklerini kontrol etmek için Android Kotlin mülakat sorularımız iyi bir kontrol listesi olur.

Altyapı ne olursa olsun, test sürecinde hızlı sürüm çıkarabilmek için otomatik derleme ve imzalama düzeni kurmanızı öneriyoruz. Böylece testçi geri bildirimi geldiğinde düzeltmeyi aynı gün yayına alırsınız.

Bir de sürüm numaralarına dikkat edin. Kapalı test kanalına her yeni paket yüklediğinizde sürüm kodunu artırmanız gerekir; aksi halde Play Console paketi kabul etmez. Test süresince kaç sürüm çıkardığınızı, her sürümde neyi düzelttiğinizi kısa notlarla kaydedin. Bu notlar, başvuru formundaki üretime hazırlık sorularına doğrudan malzeme olur ve inceleme ekibine sürecin canlı olduğunu gösterir.

Uygulamanızı mağazaya biz çıkarırsak süreç nasıl işler?

Pek çok işletme için asıl zorluk kodu yazmak değil, mağaza süreçlerini yönetmektir: geliştirici hesabı, kapalı test, testçi koordinasyonu, başvuru formu ve sonraki politika uyumu. Biz bu adımları geliştirme sürecinin içine yerleştiriyoruz.

Talha Aslan ve ekibi olarak uygulamanızı tasarlıyor, geliştiriyor, kapalı testi planlıyor, testçi görev listesini hazırlıyor, geri bildirimi topluyor ve üretim erişimi başvurusunu sizinle birlikte yazıyoruz. Hesabın sahibi ve yayıncı siz olursunuz; biz süreci yürütürüz. Projenize özel kapsam ve takvim için mobil uygulama geliştirme sayfamızdan teklif alabilirsiniz.

Eğer uygulamanız zaten hazırsa ve yalnızca mağaza süreci takıldıysa, bunu da teklif aşamasında belirtin. Mevcut kod tabanını inceleyip kapalı test ve başvuru sürecini nasıl tamamlayacağımızı ayrı bir kapsam olarak planlarız.

Başvurmadan önce son kontrol listesi

Son olarak, üretim erişimi başvuru düğmesine basmadan önce şu listeyi gözden geçirin. Her maddeye "evet" diyebiliyorsanız başvurunuz sağlam bir zemindedir:

• Kapalı test kanalında yayında bir sürüm var mı?
• En az 12 testçi son 14 gün boyunca kesintisiz katılımda kaldı mı?
• Testçiler ana akışların hepsini denedi mi ve bunu gösteren notlarınız var mı?
• Geri bildirim tablonuz ve test sırasında yaptığınız değişikliklerin listesi hazır mı?
• Ön lansman raporunda kritik çökme ya da erişilebilirlik sorunu kaldı mı?
• Giriş gerektiren uygulamalar için çalışan bir inceleme hesabı tanımladınız mı?
• Gizlilik politikası, veri güvenliği ve içerik derecelendirmesi bölümleri güncel mi?
• Başvuru cevaplarını önce ayrı bir belgede yazıp kontrol ettiniz mi?

Kısacası Google Play kapalı test şartı bir engel değil, uygulamanızı gerçek kullanıcılarla sınamanız için verilen planlı bir fırsattır. Doğru planlarsanız 14 gün sonunda hem onay almış bir başvurunuz hem de daha sağlam bir uygulamanız olur.