TestFlight Nedir? iOS Uygulamasını Yayın Öncesi Test Ettirme Rehberi

TestFlight, iOS uygulamanızı App Store'a çıkarmadan önce gerçek kişilere kurdurup denetmenin Apple'ın resmi yoludur. Bu rehberde Talha Aslan ve ekibi olarak sahada izlediğimiz akışı anlatıyoruz: iç test, dış test, beta incelemesi, davet yolları, build süresi, geri bildirim toplama ve en sık yapılan hatalar. Amaç, yayın gününe sürprizsiz gelmeniz.

Kısacası TestFlight, Xcode ile ürettiğiniz derlemeyi (build, yani uygulamanın kurulabilir paketi) mağazaya koymadan önce kontrollü bir kitleye açar. Böylece hatayı müşteri değil, sizin seçtiğiniz testçi görür. Apple'ın TestFlight sayfası bu hizmeti uygulamalar, oyunlar ve App Clip deneyimleri için tanımlıyor.

Ayrıca TestFlight yalnız hata avı için değildir. Örneğin yeni bir ödeme ekranının kullanıcıya net gelip gelmediğini, bildirim izninin doğru anda istenip istenmediğini ya da giriş akışının kaç adımda bittiğini burada ölçersiniz. Yani hem teknik hem de deneyim testi için aynı kanalı kullanırsınız.

Neden uygulamanızı yayından önce test ettirmelisiniz?

Simülatörde kusursuz görünen bir uygulama gerçek cihazda farklı davranabilir. Ekran boyutu, eski işletim sistemi sürümü, zayıf mobil veri, düşük pil modu ve farklı dil ayarlarını simülatör tam yansıtmaz. Bu nedenle gerçek cihazda, gerçek kişilerle yapılan bir tur, mağaza reddini ve kötü ilk yorumları ciddi biçimde azaltır.

Üstelik mağaza incelemesinde takılan pek çok sorun aslında testte yakalanabilecek türdendir: çöken ekranlar, çalışmayan demo hesabı, boş kalan sayfalar. Sık red sebeplerini mağaza red sebepleri rehberimizde ayrıca topladık; TestFlight turu bu listenin çoğunu önceden kapatmanızı sağlar.

Biz projelerde testi yayın planının parçası olarak görüyoruz. Mobil uygulama geliştirme hizmetimizde uygulamanızı biz geliştiriyor, TestFlight turlarını biz yönetiyor ve mağazaya da biz çıkarıyoruz. Kendi ekibinizle ilerliyorsanız aşağıdaki adımlar aynı düzeni kurmanıza yardım eder.

TestFlight'ta iç test ile dış test arasındaki fark nedir?

TestFlight iki tür testçi tanır. İç testçiler App Store Connect hesabınızda kullanıcısı olan ekip üyeleridir. Dış testçiler ise hesabınızda kullanıcısı olmayan herkes olabilir: müşteriler, gönüllüler, bayiler. Apple'ın TestFlight genel bakış sayfası iç test için 100, dış test için 10.000 kişilik üst sınır veriyor; güncel değeri bu sayfadan kontrol edin.

Pratikte iç test her yeni build'in ilk süzgecidir. Dış test ise ürünün gerçek kitleyle buluştuğu provadır. İkisini sırayla kullanmak en sağlıklı yoldur.

TestFlight kullanmaya başlamadan önce neler hazır olmalı?

TestFlight'ı açmadan önce bazı temel parçaların yerinde olması gerekir. Aksi halde ilk denemede build yüklemesi ya da test daveti sorun çıkarır. Kontrol listemiz şöyle:

• Apple Developer Program üyeliği ve App Store Connect erişimi.
• App Store Connect'te bir uygulama kaydı ve paket kimliği (bundle ID).
• Doğru imzalama sertifikası ve uygulama kimliğini içeren dağıtım profili.
• Xcode veya Xcode Cloud ile arşivlediğiniz, yüklemeye hazır bir build.
• Dış test için beta açıklaması, geri bildirim e-postası ve iletişim bilgileri.
• Giriş gerektiren uygulamalarda inceleme ekibi için çalışan bir demo hesabı.

Ayrıca ekip rollerini baştan netleştirin. Apple'ın yardım sayfalarına göre dış testçi davet etmek için Hesap Sahibi, Yönetici veya Uygulama Yöneticisi rolü gerekir. Rolü olmayan bir geliştirici build yükleyebilir ama dış grubu yönetemeyebilir; bu da son dakikada bekleme yaratır.

İlk build'i App Store Connect'e nasıl yüklersiniz?

İlk build yükleme işi Xcode'da başlar. Uygulamayı Release ayarıyla arşivlersiniz, ardından Organizer penceresinden App Store Connect'e dağıtım seçeneğini kullanırsınız. Xcode Cloud kullanıyorsanız bu adımı iş akışına bağlayıp otomatik hale getirirsiniz.

Yükleme bittikten sonra build bir süre işleme alır. Bu sırada TestFlight sekmesinde build'i görürsünüz ama hemen test edemezsiniz. İşlem tamamlanınca ihracat uyumluluğu (export compliance, şifreleme kullanımına dair beyan) sorusu çıkabilir. Bu soruyu cevaplamadan build testçilere gitmez.

Bir de sürüm numarasına dikkat edin. Her yeni yüklemede build numarasını artırmanız gerekir; aynı numarayla ikinci kez yükleme yapamazsınız. Biz sürüm numarasını kullanıcıya görünen sürüm, build numarasını ise iç sayaç olarak tutuyoruz. Böylece testçinin hangi build'de hata bulduğunu karışıklık olmadan izleriz.

Son olarak Xcode'da "yalnız iç test" seçeneğiyle yüklediğiniz build'ler sadece iç gruplara eklenebilir. Apple bu build'lerin dış teste veya mağazaya gönderilemeyeceğini belirtiyor. Dış teste çıkacaksanız yüklemeyi bu seçenek olmadan yapın.

TestFlight iç test grubunu adım adım nasıl kurarsınız?

İç test, TestFlight'ın en hızlı katmanıdır çünkü beta incelemesi beklemez. Apple'ın yardım sayfasındaki akış özetle şöyledir:

1. App Store Connect'te uygulamanızı seçin ve TestFlight sekmesine geçin.
2. Kenar çubuğunda iç test bölümünün yanındaki ekleme düğmesiyle yeni grup açın ve grubu adlandırın.
3. Grup oluştururken otomatik dağıtım seçeneğini isterseniz işaretleyin; böylece Xcode'dan gelen yeni build'ler gruba kendiliğinden gider.
4. Gruba testçi ekleyin; listede yalnız App Store Connect kullanıcılarını bulursunuz.
5. Build ekleyin ve "What to Test" alanına bu turda neyi denemelerini istediğinizi yazın.
6. Testçiler davet e-postasını alır ve TestFlight uygulamasından kurulumu yapar.

Dikkat etmeniz gereken bir ayrıntı var: Apple, Xcode Cloud ile üretilen build'leri gruplara her zaman elle eklemeniz gerektiğini söylüyor. Otomatik dağıtımı açtınız diye her build'in kendiliğinden gittiğini varsaymayın.

Örnek senaryo: beş kişilik bir ekip her akşam yeni build alır, ertesi sabah kısa bir kontrol turu yapar. Bu tempo, hataları dış teste taşımadan temizlemenizi sağlar.

Dış test için TestFlight beta incelemesi nasıl işler?

Dış teste açtığınız ilk build, Apple'ın TestFlight beta incelemesinden geçer. Bu inceleme, uygulamanızın App Store İnceleme Yönergeleri'ne genel uyumunu kontrol eder. Apple'ın dış testçi davet rehberine göre ilk build tam inceleme ister; aynı sürümün sonraki build'leri ise tam inceleme gerektirmeyebilir.

İnceleme onaylanınca Yönetici rolündeki kullanıcılara e-posta gider. Reddedilirse build durumu "Rejected" olur ve ayrıntıyı App Store Connect'teki App Review bölümünde görürsünüz. Ayrıca Apple, aynı sürümden aynı anda yalnız bir build'in incelemede olabileceğini ve 24 saat içinde gönderebileceğiniz build sayısının sınırlı olduğunu belirtiyor; güncel sınırı resmi sayfadan kontrol edin.

Biz beta incelemesini mağaza incelemesinin provası olarak kullanıyoruz. Çünkü burada aldığınız bir uyarı, büyük ihtimalle mağaza başvurusunda da karşınıza çıkacaktır. Örneğin içerik tekrarı sebebiyle gelen bir uyarı, 4.3 spam reddi konusunu erkenden gündeme getirir.

Kısacası beta incelemesini bir engel değil, erken uyarı sistemi olarak görün. Demo hesabını, ödeme akışını ve izin metinlerini bu aşamada eksiksiz verin.

Test bilgileri bölümüne ne yazmalısınız?

Dış test başlamadan önce App Store Connect sizden test bilgileri ister. Apple'ın genel bakış sayfası bu alanları şöyle sıralıyor: beta uygulama açıklaması, denemesini istediğiniz özelliklerin açıklaması ve geri bildirimlerin gideceği e-posta adresi. Bunlara ek olarak inceleme ekibi için iletişim bilgisi ve gerekiyorsa demo hesap bilgisi de girersiniz.

Beta açıklamasını kısa ve sade tutun. Testçi uygulamanın ne yaptığını iki cümlede anlamalı. Ardından testçinin deneyeceği bölümü somut yazın; "her şeyi deneyin" yerine "yeni sepet ekranını ve kuponla ödemeyi deneyin" gibi net bir görev verin.

Ayrıca inceleme notlarını ihmal etmeyin. Uygulamanız belirli bir konum, donanım ya da üyelik gerektiriyorsa bunu açıkça belirtin. Örneğin yalnız belirli bir bölgede çalışan bir hizmet uygulamasında incelemecinin hangi adımı nasıl test edeceğini yazmazsanız inceleme gecikebilir.

Son olarak geri bildirim e-postası olarak gerçekten okunan bir kutu verin. Bazı eski cihazlardaki testçiler geri bildirimi yalnız e-postayla gönderebiliyor; kimsenin bakmadığı bir adres değerli notları kaybetmenize yol açar.

TestFlight testçilerini e-postayla nasıl davet edersiniz?

E-posta daveti, kimin test ettiğini bilmek istediğiniz durumlar için en uygun yoldur. Dış grubu seçip testçiler bölümünde ekleme düğmesine basarsınız. Ardından yeni testçileri e-posta adresiyle tek tek girer, mevcut testçileri seçer veya bir CSV dosyasından toplu olarak içe aktarırsınız.

Testçi davet e-postasını alınca bağlantıya dokunur ve daveti TestFlight uygulamasıyla kabul eder. Apple'ın sayfasına göre davetli testçilerin e-posta adresi geri bildirim ayrıntısında yer alır. Bu sayede hangi notun kimden geldiğini bilir, gerekirse testçiye dönüp ek soru sorarsınız.

Bu yöntem özellikle kurumsal projelerde işe yarar. Örneğin bir bayi ağına uygulama hazırlıyorsanız her bayiden bir yetkiliyi davet eder, geri bildirimi bölgeye göre ayırırsınız. Öte yandan kişisel veri konusunda dikkatli olun; testçi listesini yalnız test amacıyla tutun ve paylaşmayın.

Bir ipucu daha: grupları amaca göre bölün. "Satış ekibi", "sadık müşteriler", "eski cihaz kullananlar" gibi ayrı gruplar, aynı build'i farklı gözlerle değerlendirmenizi kolaylaştırır.

Herkese açık TestFlight bağlantısı ne zaman mantıklıdır?

Herkese açık bağlantı (public link), kişinin iletişim bilgisini bilmeden onu teste almanızı sağlar. Bağlantıyı bir bültene, sosyal medya gönderisine veya web sitenize koyarsınız; tıklayan kişi TestFlight üzerinden katılır. Geniş kitleyle deneme yapmak istediğinizde bu yol çok pratiktir.

Bağlantıyı oluştururken iki seçenek çıkar: herkese açık bırakmak veya kriterle süzmek. Kriterle süzdüğünüzde cihaz türü ve işletim sistemi sürümü aralığı belirlersiniz. Ayrıca bağlantı için bir testçi sınırı koyarsınız; böylece bağlantı yayıldığında grubunuz kontrolsüz büyümez.

Ancak bir riski bilin: Apple, bağlantıyı herkesin paylaşabileceğini açıkça söylüyor. Bu yüzden henüz gizli kalması gereken bir ürün için herkese açık bağlantı yerine e-posta davetini tercih edin. Bağlantıyı istediğiniz an devre dışı bırakabilirsiniz.

Bir de anonimlik konusu var. Bağlantıyla katılan testçiler listede anonim yer alır; geri bildirim gönderirken e-posta yazmazlarsa kimden geldiğini bilemezsiniz. Kurulum tarihi, oturum ve çökme bilgisini ise yine görürsünüz. Dolayısıyla nicel veri için iyi, birebir görüşme için zayıf bir yoldur.

TestFlight build'i kaç gün geçerli kalır?

Apple'ın TestFlight genel bakış sayfasına göre bir build'i en fazla 90 gün test edebilirsiniz; bu sürenin sonunda build testçiler için kullanılamaz hale gelir. Süre politikası değişebileceği için güncel değeri resmi sayfadan kontrol etmenizi öneririz.

Bu sürenin pratik bir sonucu var: uzun süren bir beta programında testçilerin elindeki build sessizce sona erer. Testçi uygulamayı açamayınca uygulamanın bozulduğunu düşünebilir. Bu nedenle uzun programlarda düzenli aralıklarla yeni build yayınlayın ve testçilere süreyi önceden hatırlatın.

Öte yandan build'i süresinden önce de sonlandırabilirsiniz. Örneğin ciddi bir veri hatası bulduysanız eski build'i kapatıp düzelttiğiniz yeni build'i göndermek mantıklıdır. Apple ayrıca, sona erdirmediğiniz bir build'i mağazaya gönderdiğinizde davetli testçilerin onu yayından sonra da test etmeye devam edebildiğini belirtiyor.

Kısacası takviminize build başlangıç tarihlerini yazın. Biz projelerde süre dolmadan yaklaşık bir hafta önce yeni build'i hazır tutmayı alışkanlık haline getirdik; böylece testçi hiç boşluk yaşamaz.

Testçi uygulamayı nasıl kurar ve kullanır?

Testçi tarafı oldukça basittir ama ilk kez deneyenler için küçük takılmalar olur. Önce App Store'dan ücretsiz TestFlight uygulamasını kurar. Ardından davet e-postasındaki bağlantıya ya da herkese açık bağlantıya dokunur ve daveti kabul eder. Uygulama TestFlight içinde belirir; testçi kurulumu oradan yapar.

Kurulan beta uygulaması ana ekranda normal bir uygulama gibi durur, adının yanında küçük bir işaret taşır. Testçi isterse önceki build'lere geri dönebilir. Apple'ın sayfasına göre bir testçi paylaştığınız build'leri 30 cihaza kadar kullanabilir; güncel sınırı resmi sayfadan kontrol edin.

Testçilere kısa bir kurulum notu göndermenizi öneririz. Şu üç maddeyi yazmanız çoğu soruyu önler:

• Önce TestFlight uygulamasını kurun, sonra davet bağlantısını açın.
• Davet farklı bir Apple hesabına geldiyse aynı hesapla giriş yapın.
• Uygulama açılmıyorsa TestFlight içinden son build'i yeniden kurun.

Ayrıca Apple, belirli ayrılmış alan adlarında oluşturulan yönetilen Apple hesaplarının build test etmek için kullanılamayacağını belirtiyor. Kurumsal testçilerinizde bu durum varsa kişisel Apple hesabıyla katılmalarını isteyin.

TestFlight geri bildirimini ve ekran görüntülerini nasıl toplarsınız?

TestFlight'ın güçlü yanı geri bildirimin uygulama içinden gelmesidir. Testçi uygulamada ekran görüntüsü alır, üzerine işaret koyar, not yazar ve gönderir. Bu notlar App Store Connect'te TestFlight sekmesinin geri bildirim bölümünde ekran görüntüleri başlığı altında yer alır.

Gelen geri bildirimleri platforma, sürüme, build grubuna, işletim sistemi sürümüne ve cihaza göre filtrelersiniz. Her kaydı açıp ekran görüntüsünü ve yorumu görür, isterseniz zip dosyası olarak indirirsiniz. Ekran görüntülü geri bildirimi Xcode'da açma seçeneği de bulunuyor.

Biz geri bildirimi üç kovaya ayırıyoruz:

• Engelleyici hatalar: çökme, giriş yapamama, ödeme tamamlanmaması.
• Deneyim sorunları: kafa karıştıran metin, bulunamayan düğme, yavaş ekran.
• Öneriler: güzel ama bu sürüm için şart olmayan fikirler.

Böylece ekip her sabah önce engelleyicilere, sonra deneyim sorunlarına bakar. Öneriler ise yol haritasına girer. Ayrıca Apple, yeni geri bildirim geldiğinde tetiklenen web kancaları (webhook) ve App Store Connect API uç noktaları sunuyor; geri bildirimi kendi takip aracınıza aktarmak isterseniz bu yolu kullanırsınız.

Çökme raporlarını TestFlight'ta nasıl okursunuz?

Bir testçinin uygulaması çöktüğünde TestFlight testçiye kısa bir not ekleme imkânı verir. Bu kayıtlar geri bildirim bölümündeki çökmeler başlığında yer alır. Tabloda gönderim zamanı ve çökme ayrıntısı yer alır; her kayıt için çökme raporunu ve yorumu zip olarak indirirsiniz.

Apple'ın sayfasına göre çökme raporları belirli bir süre boyunca indirilebilir durumdadır; sayfa bu süreyi 120 gün olarak veriyor. Bu yüzden raporları zamanında indirip kendi kayıt sisteminize almanızı öneririz. Ayrıca uygulama donarak kapandığında rapor zip dosyasına eklenmeyebilir.

Raporu okurken önce hangi build ve hangi işletim sistemi sürümü olduğuna bakın. Ardından testçinin notunu okuyun; "sepete ikinci ürünü eklerken kapandı" gibi bir cümle, raporun tek başına anlatamadığı bağlamı verir. Aynı hatayı yeniden üretebiliyorsanız çözüm genellikle hızlı gelir.

Örnek senaryo: üç testçi aynı ekranda çökme bildirdi ve hepsi eski bir işletim sistemi sürümünde. Bu durumda sorun büyük ihtimalle yeni bir sistem özelliğinin eski sürümde bulunmamasıdır. Kısacası filtreleri kullanmak, sorunu dakikalar içinde daraltmanızı sağlar.

"What to Test" notunu nasıl yazmalısınız?

"What to Test" alanı, her build ile testçiye giden kısa görev notudur. Bu not ne kadar netse geri bildirim o kadar işe yarar olur. Belirsiz bir notla gönderilen build genellikle "güzel olmuş" gibi yüzeysel yorumlar toplar.

İyi bir not üç parçadan oluşur: bu build'de ne değişti, testçiden ne istiyorsunuz ve hatayı nasıl bildirmeli. Örnek bir not şöyle olabilir:

1. Bu build'de yeni üyelik ekranı ve şifre sıfırlama akışı var.
2. Lütfen yeni bir hesap açın, çıkış yapın ve şifrenizi sıfırlayıp tekrar giriş yapın.
3. Takıldığınız her adımda ekran görüntüsü alıp kısa bir not yazın.

Ayrıca bilinen hataları not içinde belirtin. Böylece testçiler zaten bildiğiniz bir sorunu tekrar tekrar göndermez. Apple bu alana yerelleştirilmiş sürümler eklemenize de izin veriyor; farklı dillerde testçiniz varsa notu kendi dillerinde yazın.

Son olarak notu kısa tutun. Testçi uzun bir metni okumaz; beş satırı geçmeyen, madde madde yazılmış bir görev listesi en iyi sonucu verir.

TestFlight'ta en sık yapılan hatalar nelerdir?

Sahada en çok karşılaştığımız takılmalar teknik olmaktan çok süreçle ilgilidir. İşte en sık gördüklerimiz:

• İhracat uyumluluğu sorusunu cevaplamamak; build "Missing Compliance" durumunda bekler ve testçiye gitmez.
• Build'i "yalnız iç test" seçeneğiyle yükleyip dış gruba eklemeye çalışmak.
• Build numarasını artırmadan yeniden yükleme denemek.
• Dış test için demo hesabı vermemek veya süresi dolmuş bir hesap vermek.
• Herkese açık bağlantıyı sınırsız bırakıp gizli bir ürünü fark etmeden yaymak.
• 90 günlük süreyi takip etmeyip testçiyi açılmayan bir uygulamayla bırakmak.
• Testçiyi App Store Connect kullanıcısı yapmadan iç gruba eklemeye çalışmak.

Bu hataların çoğunu birkaç dakikalık kontrolle önlersiniz. Bu nedenle her build öncesi kısa bir kontrol listesi kullanmanızı öneririz. Otomatik testleri de bu listeye bağlarsanız insan testçiye giden build daha temiz olur; otomasyon araçlarını Selenium, Cypress ve Playwright karşılaştırmamızda ele aldık.

Ayrıca ihracat uyumluluğu sorusunu her build'de cevaplamak istemiyorsanız, şifreleme beyanını uygulamanın yapılandırma dosyasında belirtebilirsiniz. Apple'ın şifreleme belgelerini okuyup durumunuza uygun beyanı seçin.

Testçilere ödül vermek TestFlight kurallarına uygun mu?

Hayır, para ya da herhangi bir karşılık vermek kurallara aykırıdır. Apple'ın App Store İnceleme Yönergeleri 2.2 maddesi, TestFlight kullanan uygulamaların testçilere herhangi bir karşılık, kitle fonlaması ödülü dahil, karşılığında dağıtılamayacağını açıkça söylüyor.

Aynı madde iki önemli şeyi daha belirtiyor. Birincisi, demo, beta ve deneme sürümleri App Store'a değil TestFlight'a aittir. İkincisi, TestFlight'a gönderilen uygulama genel dağıtım amacı taşımalı ve yönergelere uymalıdır. Yani TestFlight'ı mağazayı atlayan kalıcı bir dağıtım kanalı gibi kullanmamalısınız.

Ayrıca beta build'inizde önemli bir değişiklik yaptığınızda bu build'i testçilere dağıtmadan önce TestFlight incelemesine göndermeniz gerekir. Örneğin ödeme sistemi ya da içerik türü değiştiyse bunu inceleme dışında tutmaya çalışmayın.

Peki testçiyi nasıl motive edersiniz? Teşekkür e-postası, yayın notlarında isimlerine yer vermek ya da ürün ekibiyle kısa bir görüşme gibi maddi olmayan yollar kurallara aykırı düşmez. Yine de emin olmadığınız bir uygulama varsa güncel yönergeleri okuyun.

Google Play test kanalları TestFlight'tan nasıl ayrışır?

Uygulamanız hem iOS hem Android için çıkıyorsa iki tarafta test düzenini paralel kurmanız gerekir. Google Play Console'da dahili, kapalı ve açık olmak üzere üç test kanalı var. Google Play Console Yardım sayfasına göre dahili test uygulama başına 100 testçiye kadar çıkar ve standart Play politika incelemelerine tabi olmayabilir.

Kapalı testi e-posta listeleri veya Google Grupları ile seçtiğiniz kişilere açarsınız. Açık test ise Google Play'de bulunabilen ve bağlantıyla katılınan geniş bir betadır. Bu yapı TestFlight'taki iç ve dış test ayrımına benzer ama birebir aynı değildir; örneğin katılım bağlantısı yalnız uygulama durumu yayında iken çıkar.

Biz çapraz platform projelerde her iki tarafı aynı takvime bağlıyoruz. Tek kod tabanıyla iki platforma çıkan projelerde bu daha da önemlidir; bu yaklaşımı React Native rehberimizde anlattık. Android tarafında kaldırma veya politika sorunu yaşarsanız Google Play politika ihlali itiraz rehberi işinize yarar.

Kısacası iki mağazanın test kurallarını ayrı ayrı okuyun ve ortak bir kontrol listesiyle yönetin.

Örnek senaryo: iki haftalık bir TestFlight planı nasıl işler?

Aşağıdaki plan, orta ölçekli bir hizmet uygulaması için örnek senaryodur; garanti değil, başlangıç çerçevesidir. Projenizin büyüklüğüne göre süreleri uzatıp kısaltırsınız.

1. Birinci ve ikinci gün: iç gruba ilk build, temel akışların kontrolü.
2. Üçüncü ve dördüncü gün: engelleyici hataların düzeltilmesi için yeni build ve tekrar iç test.
3. Beşinci gün: dış gruba ilk build ve beta incelemesine gönderim.
4. İnceleme onayından sonra: e-postayla davet edilen küçük bir sadık kullanıcı grubu.
5. Sekizinci gün: geri bildirimin üç kovaya ayrılması ve düzeltme build'i.
6. Onuncu gün: gerekirse sınırlı herkese açık bağlantıyla daha geniş tur.
7. İkinci haftanın sonu: son build, mağaza metinleri ve ekran görüntüleriyle yayın başvurusu.

Bu planın en önemli parçası her turun sonunda kısa bir değerlendirme yapmaktır. Hangi hata kapandı, hangisi sonraki sürüme kaldı, testçi neyi anlamadı? Bu soruların cevabını yazılı tutarsanız yayın kararını veriyle verirsiniz.

Ayrıca plan boyunca testçilerle iletişimi kesmeyin. Her yeni build'de kısa bir not, katılımı canlı tutar.

Testçi kitlesini nasıl seçmelisiniz?

Doğru testçi, doğru geri bildirim demektir. Uygulamayı yalnız ekip içinden kişilere test ettirirseniz akışı zaten bilen insanlardan yorum alırsınız. Bu yüzden dış testte hedef kitlenize benzeyen ama ürünü hiç görmemiş kişilere yer açın.

Biz testçi kitlesini genellikle üç katmana ayırıyoruz. İlk katman ekip ve yakın paydaşlardır; teknik hataları hızla bulurlar. İkinci katman sadık müşteriler ya da işletmenin sahadaki çalışanlarıdır; gerçek iş akışını bilirler. Üçüncü katman ise ürünü ilk kez gören kişilerdir; ilk izlenimi en dürüst onlar verir.

Öte yandan cihaz çeşitliliğini de gözetin. Yalnız en yeni telefonlarda test ederseniz eski cihazlardaki yavaşlığı göremezsiniz. Herkese açık bağlantının kriter seçeneği, işletim sistemi sürümüne göre süzme imkânı verdiği için bu dengeyi kurmanıza yardım eder.

Son olarak testçi sayısının çok olması tek başına iyi değildir. Sorulara cevap veren yirmi ilgili testçi, hiç geri bildirim göndermeyen yüzlerce kişiden daha değerlidir.

Testten mağazaya: uygulamanızı yayına nasıl hazırlarsınız?

TestFlight turu bittiğinde elinizde hem temiz bir build hem de gerçek kullanıcı verisi olur. Bu noktada mağaza sayfası metinleri, ekran görüntüleri, gizlilik bilgileri ve inceleme notları hazırlanmalıdır. Test sırasında testçilerin en çok sorduğu sorular, mağaza açıklamanızın ilk satırlarına girmeye aday konulardır.

Ayrıca son build'in testte kullandığınız build ile aynı olmasına dikkat edin. Testten geçmemiş bir son dakika değişikliği, tüm turun emeğini boşa çıkarabilir. Teknik ekip mülakatlarında bu disiplini nasıl sorduğumuzu merak ediyorsanız iOS Swift geliştirici mülakat soruları yazımıza göz atabilirsiniz.

Bu sürecin tamamını tek elden yürütmek isterseniz yanınızdayız. Uygulamanızı biz geliştirir, TestFlight turlarını biz yönetir ve mağazaya biz çıkarırız. Projeniz için mobil uygulama geliştirme hizmetimiz üzerinden teklif alabilir, kapsamı ve takvimi birlikte netleştirebilirsiniz.

Kısacası TestFlight, iyi kullanıldığında yayın gününü bir sınav olmaktan çıkarıp planlı bir adıma dönüştürür.